The document provides an introduction to automated testing and its benefits. It discusses how automated testing allows code to be checked programmatically, freeing up human time and ensuring tests are run consistently. Key benefits mentioned include catching bugs early, enabling refactoring with confidence, and producing more informative bug reports.
Unit testing patterns for concurrent codeDror Helper
Getting started with unit testing is not hard, the only problem is that most programs are more than a simple calculator with two parameters and a returns value that is easy to verify.
Writing unit tests for multi-threaded code is harder still.
Over the years I discovered useful patterns that helped me to test multi-threaded and asynchronous code and enabled the creation of deterministic, simple and robust unit tests.
Come learn how to test code that uses concurrency and parallelism – so that the excuses of not writing unit tests for such code would become as obsolete as a single core processors.
The document discusses testing techniques and principles for writing tests. It advocates for tests that are FAST, ISOLATING, REPEATABLE, SELF-VALIDATING, and TIMELY (FIRST). It also discusses the Arrange-Act-Assert (AAA) structure for tests and how to achieve high code coverage while maintaining test quality. The document notes that while code coverage is a useful metric, it does not guarantee correctness on its own. It also covers the use of test doubles like stubs, spies, mocks and fakes to replace dependencies.
(automatic) Testing: from business to university and backDavid Rodenas
This talk cares about the fundamentals of testing, a little bit history of how the professional community developed what we currently know as testing, but also about why I should care about testing? why is it important to do a test? What is important to test? What is not important to test? How to do testing?
There some examples in plnker just to see each step, and many surprises.
This talk also compares what people learned in the Computer Sciences and Engineering degrees and what people does in testing. It gives some tips to catch up with current state of art and gives some points to start changing syllabus to make better engineers.
This talk is good for beginners, teachers, bosses, but also for seasoned techies that just want to light up some of the ideas that they might have been hatching.
Spoiler alert: testing will save you development time and make you a good professional.
Testing, Learning and Professionalism — 20171214David Rodenas
Two hours talk about testing, its history, its meaning and propose, a small guide of good practices, and what it is supposed to be a good professional and what is expected from us the professionals.
Unit Testing: The Whys, Whens and Hows discusses unit testing definitions, benefits, and best practices. It covers:
- Defining what constitutes a unit test and different testing styles. Unit tests should be written by developers, run fast, be deterministic, and not integrate multiple areas of code.
- Benefits of unit testing include better code quality, a safety net for refactoring, documentation of functionality, and preventing code from becoming untestable.
- Characteristics of good unit tests like being functionally correct, running independently, running fast, and adding new tests for bugs fixed. Good code is more unit testable through interfaces, contracts, and low dependencies.
The Ring programming language version 1.6 book - Part 41 of 189Mahmoud Samir Fayed
This document discusses using the Natural library in Ring to define a natural language for programming.
It shows an example of a demo program that loads the Natural library, defines a language called "MyLanguage" with commands in a folder, and uses the "Hello" and "Count" commands. Command classes are defined that belong to the "MyLanguage.Natural" package.
The Natural library provides methods like SetLanguageName(), SetCommandsPath(), SetPackageName(), UseCommand(), RunFile() to define the natural language. DefineNaturalCommand defines syntax like keyword, keyword with numbers, to specify command parameters. This allows writing natural code that can be interpreted and executed.
How difficult is to automatically test the HelloWorld.
We fix it and other many difficult scenarios with techniques like:
- lower "s" singleton
- law of demeter
- dependency injection
- and more examples
1. The document discusses good and bad practices for writing unit tests. It emphasizes that tests should verify the expected behavior, fail clearly when something goes wrong, and use mocks and isolation to focus on the code being tested.
2. Some examples of bad tests shown include tests that don't make assertions or assertions that don't provide useful information on failure. Real objects are also used instead of mocks, obscuring the test.
3. Good practices include using mocks to isolate the code being tested, making sure tests fail clearly when something goes wrong, and focusing tests on expected behavior through clear assertions. Automated testing, fixing broken tests, and mastering testing tools are also emphasized.
Unit testing patterns for concurrent codeDror Helper
Getting started with unit testing is not hard, the only problem is that most programs are more than a simple calculator with two parameters and a returns value that is easy to verify.
Writing unit tests for multi-threaded code is harder still.
Over the years I discovered useful patterns that helped me to test multi-threaded and asynchronous code and enabled the creation of deterministic, simple and robust unit tests.
Come learn how to test code that uses concurrency and parallelism – so that the excuses of not writing unit tests for such code would become as obsolete as a single core processors.
The document discusses testing techniques and principles for writing tests. It advocates for tests that are FAST, ISOLATING, REPEATABLE, SELF-VALIDATING, and TIMELY (FIRST). It also discusses the Arrange-Act-Assert (AAA) structure for tests and how to achieve high code coverage while maintaining test quality. The document notes that while code coverage is a useful metric, it does not guarantee correctness on its own. It also covers the use of test doubles like stubs, spies, mocks and fakes to replace dependencies.
(automatic) Testing: from business to university and backDavid Rodenas
This talk cares about the fundamentals of testing, a little bit history of how the professional community developed what we currently know as testing, but also about why I should care about testing? why is it important to do a test? What is important to test? What is not important to test? How to do testing?
There some examples in plnker just to see each step, and many surprises.
This talk also compares what people learned in the Computer Sciences and Engineering degrees and what people does in testing. It gives some tips to catch up with current state of art and gives some points to start changing syllabus to make better engineers.
This talk is good for beginners, teachers, bosses, but also for seasoned techies that just want to light up some of the ideas that they might have been hatching.
Spoiler alert: testing will save you development time and make you a good professional.
Testing, Learning and Professionalism — 20171214David Rodenas
Two hours talk about testing, its history, its meaning and propose, a small guide of good practices, and what it is supposed to be a good professional and what is expected from us the professionals.
Unit Testing: The Whys, Whens and Hows discusses unit testing definitions, benefits, and best practices. It covers:
- Defining what constitutes a unit test and different testing styles. Unit tests should be written by developers, run fast, be deterministic, and not integrate multiple areas of code.
- Benefits of unit testing include better code quality, a safety net for refactoring, documentation of functionality, and preventing code from becoming untestable.
- Characteristics of good unit tests like being functionally correct, running independently, running fast, and adding new tests for bugs fixed. Good code is more unit testable through interfaces, contracts, and low dependencies.
The Ring programming language version 1.6 book - Part 41 of 189Mahmoud Samir Fayed
This document discusses using the Natural library in Ring to define a natural language for programming.
It shows an example of a demo program that loads the Natural library, defines a language called "MyLanguage" with commands in a folder, and uses the "Hello" and "Count" commands. Command classes are defined that belong to the "MyLanguage.Natural" package.
The Natural library provides methods like SetLanguageName(), SetCommandsPath(), SetPackageName(), UseCommand(), RunFile() to define the natural language. DefineNaturalCommand defines syntax like keyword, keyword with numbers, to specify command parameters. This allows writing natural code that can be interpreted and executed.
How difficult is to automatically test the HelloWorld.
We fix it and other many difficult scenarios with techniques like:
- lower "s" singleton
- law of demeter
- dependency injection
- and more examples
1. The document discusses good and bad practices for writing unit tests. It emphasizes that tests should verify the expected behavior, fail clearly when something goes wrong, and use mocks and isolation to focus on the code being tested.
2. Some examples of bad tests shown include tests that don't make assertions or assertions that don't provide useful information on failure. Real objects are also used instead of mocks, obscuring the test.
3. Good practices include using mocks to isolate the code being tested, making sure tests fail clearly when something goes wrong, and focusing tests on expected behavior through clear assertions. Automated testing, fixing broken tests, and mastering testing tools are also emphasized.
This document discusses 10 typical problems seen in enterprise Java applications. Problem #6 is having no data access object (DAO) layer, resulting in services directly using persistence mechanisms like JPA or JDBC. This makes code impossible to test without a database, tightly couples services to persistence, and provides no structure for adding data-dependent features like security. The solution is to use a DAO layer to abstract away the persistence, separating this technical concern from the service layer.
The Ring programming language version 1.5.1 book - Part 37 of 180Mahmoud Samir Fayed
The Natural Library allows defining a natural language on top of Ring. It provides methods to set the language name, commands path, package name, use commands, set operators, and run files or strings. An example program loads the library, defines a natural language class, and runs natural text from a file to demonstrate a simple but complete natural language program.
10 Typical Problems in Enterprise Java ApplicationsEberhard Wolff
This presentation shows some typical problems that you will find in far too many Enterprise Java Applications. It is the result of quite a few code reviews I did as a consultant.
Introduction to web programming for java and c# programmers by @drpicoxDavid Rodenas
(better presented by @drpicox)
Slides of an introductory course for web programming focusing in basic Javascript and CSS concepts. It assumes knowledge of programming, Java or C#.
DataStax: Making Cassandra Fail (for effective testing)DataStax Academy
This document discusses testing Cassandra applications by making Cassandra fail deterministically. It introduces Stubbed Cassandra, a tool that allows priming Cassandra to respond to queries and prepared statements with different failures like timeouts, unavailability, and coordinator issues. Tests can verify application behavior and retries under failures. Stubbed Cassandra runs as a separate process and exposes REST APIs to prime failures and verify query activity, allowing integration into testing frameworks. It aims to help test edge cases and fault tolerance more effectively than existing Cassandra testing tools.
Here are some suggestions to improve the test method name:
- shouldReturnNullWhenQueryReturnsNull
- shouldPassNullFromDaoWhenQueryReturnsNull
Using "should" makes the intent clearer - we expect the method to return null under certain conditions. Describing those conditions ("when query returns null") in the name provides more context than a generic "testQuery".
Overall, test method names should clearly communicate what is being tested and under what conditions we expect the test to pass or fail. This helps readers understand the purpose and focus of each test.
Cassandra Summit EU 2014 - Testing Cassandra ApplicationsChristopher Batey
The document discusses testing Cassandra applications. It introduces Stubbed Cassandra, a tool that allows embedding a Cassandra server in unit tests to prime responses and verify queries. It can start multiple instances in a test, prime different result types, and verify connections and prepared statements. Example tests show how to test queries, errors, retries, and slow connections. Future features may include loading schemas and simulating multiple nodes.
From Elixir to Akka (and back) - ElixirConf Mx 2017Agustin Ramos
From Elixir to Akka (and back)
The document compares the Actor Model as implemented in Elixir and Akka. It discusses key differences in how messages are passed, mailboxes are handled, scheduling works, and monitoring capabilities between the two frameworks. It ultimately concludes that Akka adds unnecessary complexity on top of the JVM compared to Elixir's cleaner implementation of the Actor Model.
There are lots of talks about testing: they talk about syntax, methodologies, tools. But there is usually a missing point: Why it is important to do a test? What is important to test? What is not important to test? How to do testing?
There lots of examples in plnker just to see each step, and many surprises.
This talk is good for beginners, but also for some seasoned people that just want to light up some of the ideas that they might have been hatching.
Spoiler alert: testing will save you development time.
Cassandra is great but how do I test my application?Christopher Batey
The document discusses testing Cassandra applications and introduces Stubbed Cassandra, a tool for testing Cassandra drivers. Stubbed Cassandra allows priming a fake Cassandra server to return expected responses or errors. It can be used to test failure scenarios, edge cases, and retry policies. The tool has Java and REST APIs and makes it possible to quickly test Cassandra applications in a deterministic and non-brittle way.
As a guest speaker in NCU, I gave this second talk about some more advanced practices of JavaScript programming. It summarised our experience learned from developing Mozilla/Gaia project, including the way to deal with asynchronous code flow with the event-driven model.
The Ring programming language version 1.8 book - Part 44 of 202Mahmoud Samir Fayed
This document discusses using the Ring programming language to create natural language programming. It provides examples of how to define classes to handle natural language statements and change keywords, operators, and handling errors. Key examples include changing the "and" keyword, changing the "+" operator, handling multiple instructions, and accepting literal text instead of strings. The document demonstrates how to evaluate natural code using Eval() and handle errors using BraceError().
ES3-2020-06 Test Driven Development (TDD)David Rodenas
Basics of TDD. Including why? Why it is discipline. Typical Pitfalls. Kinds of TDD, and a Recipe so anyone can do testing quickly. And lots of examples.
The document discusses concepts related to concurrent and parallel programming with threads in Java. It covers key topics such as concurrent programming using threads, challenges with shared mutable state and data visibility across threads, and improvements in Java like the ConcurrentHashMap that provide better concurrency support. It emphasizes that achieving parallelism requires minimizing shared mutable state and synchronization through techniques like immutable objects and data-oriented design.
PVS-Studio analyzer is continuously improving, and the C#-code analysis module is developing most actively: ninety new diagnostic rules were added in 2016. However, the best way to estimate the analyzer's efficiency is to look at the bugs it can catch. It's always interesting, as well as useful, to do recurring checks of large open-source projects at certain intervals and compare their results. Today I will talk about the results of the second analysis of SharpDevelop project.
Clean code via dependency injection + guiceJordi Gerona
The document discusses various code smells related to dependency injection and constructor usage, such as constructors doing real work instead of just setting fields, digging into collaborator objects instead of using their interfaces, and relying on global state and singletons. It provides examples of these code smells and proposes fixes using dependency injection and interfaces to make the code more testable and flexible.
P U N I S H M E N T A N D P R A Y A S H C H I T T A D Rbanothkishan
Punishment is judgmental and can involve contempt, but not all punishments are legal. Sins come from incorrect perceptions, feelings, and intentions, and can be errors, mistakes, misdeeds or crimes that harm oneself or others, making one unaware of the Truth. Not all sins are illegal. Prayashchitta is any action that leads one to realize the Truth. The Truth is a state of unity, connectivity, and benevolence beyond words. Repeating names of God (Namasmran) can wake one up to realize the Truth.
This document provides instructions for using various online tools and software to analyze linkage disequilibrium and select tag SNPs for a given gene or genomic region. It outlines how to use the SeattleSNPs website tools Visual Genotype and Visual Haplotype to view genotype and haplotype data, determine linkage disequilibrium, and select tag SNPs. It also describes how to use external tools LDSelect, HaploBlockFinder, Haploview, and downloading data from HapMap to further analyze tag SNPs and linkage disequilibrium.
This document discusses 10 typical problems seen in enterprise Java applications. Problem #6 is having no data access object (DAO) layer, resulting in services directly using persistence mechanisms like JPA or JDBC. This makes code impossible to test without a database, tightly couples services to persistence, and provides no structure for adding data-dependent features like security. The solution is to use a DAO layer to abstract away the persistence, separating this technical concern from the service layer.
The Ring programming language version 1.5.1 book - Part 37 of 180Mahmoud Samir Fayed
The Natural Library allows defining a natural language on top of Ring. It provides methods to set the language name, commands path, package name, use commands, set operators, and run files or strings. An example program loads the library, defines a natural language class, and runs natural text from a file to demonstrate a simple but complete natural language program.
10 Typical Problems in Enterprise Java ApplicationsEberhard Wolff
This presentation shows some typical problems that you will find in far too many Enterprise Java Applications. It is the result of quite a few code reviews I did as a consultant.
Introduction to web programming for java and c# programmers by @drpicoxDavid Rodenas
(better presented by @drpicox)
Slides of an introductory course for web programming focusing in basic Javascript and CSS concepts. It assumes knowledge of programming, Java or C#.
DataStax: Making Cassandra Fail (for effective testing)DataStax Academy
This document discusses testing Cassandra applications by making Cassandra fail deterministically. It introduces Stubbed Cassandra, a tool that allows priming Cassandra to respond to queries and prepared statements with different failures like timeouts, unavailability, and coordinator issues. Tests can verify application behavior and retries under failures. Stubbed Cassandra runs as a separate process and exposes REST APIs to prime failures and verify query activity, allowing integration into testing frameworks. It aims to help test edge cases and fault tolerance more effectively than existing Cassandra testing tools.
Here are some suggestions to improve the test method name:
- shouldReturnNullWhenQueryReturnsNull
- shouldPassNullFromDaoWhenQueryReturnsNull
Using "should" makes the intent clearer - we expect the method to return null under certain conditions. Describing those conditions ("when query returns null") in the name provides more context than a generic "testQuery".
Overall, test method names should clearly communicate what is being tested and under what conditions we expect the test to pass or fail. This helps readers understand the purpose and focus of each test.
Cassandra Summit EU 2014 - Testing Cassandra ApplicationsChristopher Batey
The document discusses testing Cassandra applications. It introduces Stubbed Cassandra, a tool that allows embedding a Cassandra server in unit tests to prime responses and verify queries. It can start multiple instances in a test, prime different result types, and verify connections and prepared statements. Example tests show how to test queries, errors, retries, and slow connections. Future features may include loading schemas and simulating multiple nodes.
From Elixir to Akka (and back) - ElixirConf Mx 2017Agustin Ramos
From Elixir to Akka (and back)
The document compares the Actor Model as implemented in Elixir and Akka. It discusses key differences in how messages are passed, mailboxes are handled, scheduling works, and monitoring capabilities between the two frameworks. It ultimately concludes that Akka adds unnecessary complexity on top of the JVM compared to Elixir's cleaner implementation of the Actor Model.
There are lots of talks about testing: they talk about syntax, methodologies, tools. But there is usually a missing point: Why it is important to do a test? What is important to test? What is not important to test? How to do testing?
There lots of examples in plnker just to see each step, and many surprises.
This talk is good for beginners, but also for some seasoned people that just want to light up some of the ideas that they might have been hatching.
Spoiler alert: testing will save you development time.
Cassandra is great but how do I test my application?Christopher Batey
The document discusses testing Cassandra applications and introduces Stubbed Cassandra, a tool for testing Cassandra drivers. Stubbed Cassandra allows priming a fake Cassandra server to return expected responses or errors. It can be used to test failure scenarios, edge cases, and retry policies. The tool has Java and REST APIs and makes it possible to quickly test Cassandra applications in a deterministic and non-brittle way.
As a guest speaker in NCU, I gave this second talk about some more advanced practices of JavaScript programming. It summarised our experience learned from developing Mozilla/Gaia project, including the way to deal with asynchronous code flow with the event-driven model.
The Ring programming language version 1.8 book - Part 44 of 202Mahmoud Samir Fayed
This document discusses using the Ring programming language to create natural language programming. It provides examples of how to define classes to handle natural language statements and change keywords, operators, and handling errors. Key examples include changing the "and" keyword, changing the "+" operator, handling multiple instructions, and accepting literal text instead of strings. The document demonstrates how to evaluate natural code using Eval() and handle errors using BraceError().
ES3-2020-06 Test Driven Development (TDD)David Rodenas
Basics of TDD. Including why? Why it is discipline. Typical Pitfalls. Kinds of TDD, and a Recipe so anyone can do testing quickly. And lots of examples.
The document discusses concepts related to concurrent and parallel programming with threads in Java. It covers key topics such as concurrent programming using threads, challenges with shared mutable state and data visibility across threads, and improvements in Java like the ConcurrentHashMap that provide better concurrency support. It emphasizes that achieving parallelism requires minimizing shared mutable state and synchronization through techniques like immutable objects and data-oriented design.
PVS-Studio analyzer is continuously improving, and the C#-code analysis module is developing most actively: ninety new diagnostic rules were added in 2016. However, the best way to estimate the analyzer's efficiency is to look at the bugs it can catch. It's always interesting, as well as useful, to do recurring checks of large open-source projects at certain intervals and compare their results. Today I will talk about the results of the second analysis of SharpDevelop project.
Clean code via dependency injection + guiceJordi Gerona
The document discusses various code smells related to dependency injection and constructor usage, such as constructors doing real work instead of just setting fields, digging into collaborator objects instead of using their interfaces, and relying on global state and singletons. It provides examples of these code smells and proposes fixes using dependency injection and interfaces to make the code more testable and flexible.
P U N I S H M E N T A N D P R A Y A S H C H I T T A D Rbanothkishan
Punishment is judgmental and can involve contempt, but not all punishments are legal. Sins come from incorrect perceptions, feelings, and intentions, and can be errors, mistakes, misdeeds or crimes that harm oneself or others, making one unaware of the Truth. Not all sins are illegal. Prayashchitta is any action that leads one to realize the Truth. The Truth is a state of unity, connectivity, and benevolence beyond words. Repeating names of God (Namasmran) can wake one up to realize the Truth.
This document provides instructions for using various online tools and software to analyze linkage disequilibrium and select tag SNPs for a given gene or genomic region. It outlines how to use the SeattleSNPs website tools Visual Genotype and Visual Haplotype to view genotype and haplotype data, determine linkage disequilibrium, and select tag SNPs. It also describes how to use external tools LDSelect, HaploBlockFinder, Haploview, and downloading data from HapMap to further analyze tag SNPs and linkage disequilibrium.
The document discusses the agony and misery caused by pain, sorrow, conflict, feelings of absurdity, and the awareness of impermanence. These dark forces can possess anyone regardless of their status and will affect everyone at some point. While Namasmaran is proposed as a solution, the author admits they have not yet experienced freedom from these dark forces or the envisioned "SUPERJOY." The author speculates that if billions of people practice Namasmaran together, it may lead to experiencing this SUPERJOY.
The document appears to discuss criminal plans and activities involving regional killer Boyden Gray, including induced breathlessness sprayings, mixing of infectious diseases and altered medicines targeting youth, and the creation of child assassins in October 2009. Links are provided to criminal reports and affidavits filed regarding these alleged plans and activities.
_______________________________________________________________
The document contains rare photos from the Third Reich preserved by Life magazine, including images of top Nazi leaders such as Heinrich Himmler, Hermann Goering, and Arthur Seyss-Inquart. There are also photos of Nazi propaganda posters promoting violence against enemies and territorial expansion. The final photos show the destruction of Berlin in 1945, including the burned-out Gestapo headquarters.
The System of Rice Intensification (SRI) is an agricultural method developed in Madagascar in the 1980s that has led to increased rice yields. SRI involves transplanting young seedlings with wider spacing, reducing water levels, and increasing soil aeration. These practices promote increased root and soil biomass growth. Field trials show SRI can increase average rice yields by 50-100% with fewer inputs, while reducing costs, water use, and risks for farmers. SRI is now being adopted by farmers in over 30 countries in Asia, Africa, and Latin America.
The document discusses the benefits of exercise for mental health. Regular physical activity can help reduce anxiety and depression and improve mood and cognitive functioning. Exercise causes chemical changes in the brain that may help protect against mental illness and improve symptoms.
1) There is a global consensus against child labor but it continues due to shortcomings in educational policy.
2) Mainstream education in countries like India cuts students off from practical skills and focuses too much on academics, making them unprepared for the job market.
3) This leads to high unemployment and dropouts who become vulnerable to child labor. Regular practice of Namasmaran, remembering the name of God, could help address these issues by nurturing students' cognitive, affective, and psychomotor development.
Insects make up 73% of the world's living organisms and have bodies divided into three parts - head, thorax, and abdomen. They go through life stages of egg, larva, pupae, and adult. Insects can eat using mandibles, tube-like mouthparts, or sponge-like mouthparts and move by flying, crawling, jumping, or swimming. While their communication is rudimentary, some argue insects coordinate behaviors through visual cues or behaviors like the bee dance.
Namasmaran And Romance Dr Shriniwas Janardan Kashalikarbanothkishan
The document discusses the concept of Namasmaran and how it relates to everyday life and romance. It was initially thought that Namasmaran was something only for people who had resigned from active life, but it is becoming clear that it is actually a process of conscious evolution that makes individuals more objective, considerate, and able to react understandingly. Namasmaran can play a pivotal role in enriching everyday life and blossoming and immortalizing romance throughout one's life if embraced from a young age.
Shambhvi A Bestseller Marathi Novel Dr Shriniwas Kashalikarbanothkishan
The document discusses the history and importance of chocolate in human civilization. It notes that chocolate originated in Mesoamerica over 3000 years ago and was prized by the Aztecs and Mayans for its taste. Cocoa beans were used as currency and their cultivation was tightly regulated. The Spanish brought cocoa to Europe in the 16th century, starting its global spread and the development of the chocolate industry.
New Study Of Gita Nov 5 Dr Shriniwas J Kashalikarbanothkishan
Dr. Shriniwas Janardan Kashalikar conducted a new study of the Bhagavad Gita. Initially, he had several misconceptions about the Gita and felt it was too individualistic to address social issues. Through persistent study, he came to realize that the Gita deals with the war within each individual between the higher and lower self, and how responding to this war impacts both individuals and society. He understood that by guiding individuals to live according to their dharma, the Gita can help rejuvenate and revive society as a whole. His study helped resolve his doubts and reservations about how the Gita can provide guidance for both individuals and the world today.
The document discusses different types of balloons including standard roses, mylar, and latex balloons. It provides details on their colors, sizes, longevity, and wholesale pricing. Additionally, it covers helium versus air filled balloons and new balloon types that can increase float time using aqueous solutions. The document recommends techniques for balloon bouquets and arches and concludes with an activity having participants fill and monitor different balloon types.
The document provides information about online professional learning communities (PLCs) including trends in education, tools that can be used to create online PLCs, and examples of how these tools can be used in classroom and school settings. It encourages educators to start small by focusing on a few key tools and to support each other in learning new technologies over time in order to improve education.
New Study Of Gita Nov 5 Dr. Shriniwas J. Kashalikarbanothkishan
The document summarizes the author's journey in studying the Bhagavad Gita. Initially, the author struggled to understand some of the concepts and their relevance. Over time, through persistent study and reflection, the author gained new insights. They realized that the Gita deals with the eternal inner war between higher and lower selves, and how surrendering to the lower self impacts individuals and society. The author also understood that the Gita's purpose is not to provide a specific blueprint, but to inspire people to create a blueprint for universal welfare. This resolved the author's previous view that the Gita was too individualistic.
M A U N A ( S I L E N C E) & S U P E R L I V I N G D R S H R I N I W A S ...banothkishan
This document discusses the benefits of silence based on teachings from ancient Sanskrit texts. It provides several reasons why silence is recommended during certain activities like defecation, urination, sexual intercourse, bleeding, cleaning teeth, and eating. Silence allows one to focus on internal processes and avoid external distractions. It is seen as a preliminary step toward achieving true inner silence and peace. Maintaining silence can also provide practical benefits, as inappropriate speech can lead to problems while silence allows one to remain free. Overall, the document emphasizes that our ancestors understood the importance of regulating speech and embracing silence.
Professor Hanson Hosein's lecture slides from his Multimedia Storytelling class at the University of Washington's Master of Communication in Digital Media. Video was stripped.
The document outlines a program agenda for a PeopleTools advanced tips and techniques presentation. The agenda includes sections on communities and resources, extending the PeopleTools application server, web server, integration broker, and user interface using techniques like IScripts and Ajax. Screenshots are included throughout.
Test::Tutorial provides documentation on testing code in Perl. It discusses the importance of testing, different types of testing like automated testing, and reasons to write tests. Key points include: testing checks code functionality, catches bugs, and promotes code that is easier to change and maintain over time. Automated tests run quickly and help developers feel confident making changes without breaking existing features.
This document provides an overview of Perl testing with Test::Simple and Test::More. It discusses why testing is important, basic tests with ok(), and more advanced matching functions like is(), like(), and can_ok() provided by Test::More. It also covers controlling test flow using skip(), todo(), diag(), pass(), and fail(). The goal is to introduce Perl testing and help readers feel comfortable writing and using tests.
This document provides an overview of Perl testing with Test::Simple and Test::More. It discusses why testing is important, basic tests with ok(), and more advanced matching and behavior tests using functions like is(), like(), can_ok(), and skip(). It also covers controlling test flow with functions like diag(), pass(), and fail(). The goal is to introduce Perl testing and help readers feel comfortable writing and using tests.
This article describes how to test Perl programs with the excellent "Test::Class" module. It brings xUnit style testing to Perl. I explain many advanced tips and techniques which even experienced users of "Test::Class" might not be aware of.
The formatting is handled by an experimental piece of software I'm writing which turns Perl's POD format into beautiful postscript files.
Short introduction to the basics of Perl testing and some resources for further reading. Includes basics of Test::Simple, Test::More, using Inline for multi-language testing, testing coverage, testing tests.
This document provides an overview of software testing concepts. It discusses different types of testing like unit testing, functional testing, error path testing, boundary value testing, and equivalence partitioning. It also covers test strategies like golden path testing, black box testing, and white box testing. The purpose of a tester is explained as quantifying risk to make decisions that improve confidence and quality.
Seconda serata di introduzione al Test-Driven Development, tenuta in XPeppers a Trento il 24 Ottobre 2012.
Nelle slide c'è anche la descrizione del coding dojo sullo string calculator che abbiamo svolto assieme.
This document provides an overview of test-driven development (TDD) and discusses:
- The key steps of TDD including writing a test, seeing it fail, writing code to pass the test, and refactoring.
- Popular Python testing tools like unittest, nose, pytest, and sure that can be used for TDD.
- How TDD is applied to JavaScript/CoffeeScript using frameworks like Mocha, Should.js, and Expect.js.
- The benefits of TDD including early detection of errors, improved design, and serving as documentation for code changes.
Software Testing - Invited Lecture at UNSW Sydneyjulien.ponge
This document provides an overview of software testing concepts and the JUnit testing framework. It discusses the importance of testing, different types of testing, unit testing with JUnit, best practices for writing tests, integrating tests into builds with Ant and Maven, and logging. Examples of JUnit tests are also provided. The key points covered are:
- Why testing is important to find bugs, prevent regressions, and allow for refactoring
- Unit testing, functional testing, and other types of testing
- How to write automated unit tests with JUnit
- Best practices like testing edge cases, achieving good code coverage
- Integrating tests into builds with Ant and Maven
- Using logging frameworks like Log
Want to know the case for Test-Driven Development? Want to know style tips and gotchas for Testing and TDD? Let Alex Chaffee, former Mad Scientist at Pivotal Labs, tell you everything you didn't know you didn't know about testing.
Performance benchmarks are all too often inaccurate. This talk introduces some things to look for in setting up and running benchmarks to make them effective.
The $path to knowledge: What little it take to unit-test Perl.Workhorse Computing
Metadata-driven lazyness, Perl, and Jenkins provide a nice mix for automated testing. With Perl the only thing required to start testing is a files path, from there the possibilities are endless. Using Symbol's qualify_to_ref makes it easy to validate @EXPORT & @EXPORT_OK, knowing the path makes it easy to use "perl -wc" to get diagnostics.
The beautiful thing is all of it can be lazy... er, "automated". And repeatable. And simple.
This document discusses best practices for writing unit tests. It emphasizes that unit tests should be easy to understand, trustworthy, and robust. A good unit test only fails if a bug is introduced or requirements change. The document provides examples of well-written unit tests and discusses how to avoid common problems like fragile tests. It stresses the importance of testing only specified functionality, using isolation frameworks to mock dependencies, and not putting test logic in the test. Overall, the document promotes writing "clean tests" to avoid brittle tests and minimize maintenance overhead.
This document summarizes key points about developer testing based on a presentation given by Vaidas Pilkauskas. It discusses 15 things to know about testing, including test phases (setup, exercise, verify, teardown), testing behavior not methods, using matchers for assertions, custom matchers, ignoring tests, exceptions, asynchronous code, controlling time in tests, collections, access modifiers, random values, number of assertions, test doubles, naming conventions, and comments. The overall message is that tests should have clear intentions, follow best practices like the single responsibility principle, and focus on testing public behavior rather than implementation details.
TDD involves an iterative process of designing, testing, and implementing code. It begins with writing a test that fails, then implementing the minimum code to pass the test, and refactoring as needed. The document provides an example of using TDD to develop an "add" function in Perl, including writing tests using the Test::More library that validate different cases like number of arguments and argument types. It also briefly discusses testing libraries for other languages like Javascript's QUnit.
This document discusses Perl testing libraries and frameworks. It provides an overview of the history of Perl testing including Test::More and Test::Class. It also introduces some newer testing libraries like Test::Pretty, Test::Ika, and Test::Kantan that aim to improve on Test::Builder and provide additional features like BDD-style testing and improved output. The document encourages trying out these new testing libraries and frameworks.
O CPAN tem as ferramentas que você precisa para fazer TDD em Perl, o Coding D...Rodolfo Carvalho
Rodolfo Carvalho discussed Test-Driven Development (TDD) in Perl. He covered how to write tests first using modules like Test::More and Test::Most, then code to pass the tests. An example was provided of incrementally developing a Fibonacci function using TDD. He also discussed testing web applications with Test::WWW::Mechanize and Test::Mojo. Finally, he promoted regular coding dojos as a way to practice TDD in pairs and learn from others.
utPLSQL offers a unit testing API for PL/SQL that is modeled on the xUnit approach. This is an old slide deck on utPLSQL so my apologies for any inconsistencies with the current utility. Note: while I created the original utPLSQL code base, I am not actively working on utPLSQL at this time. Check out github.com/utplsql for the code and project details.
This document provides a help and tutorial for TopStyle Pro version 3.11. It covers getting started with TopStyle, editing style sheets and HTML/XHTML, working with colors, previews, validation, site management, reports, mappings, customization, and third-party integration. It also includes appendices on CSS basics and tips, TopStyle tips and tricks, style sheet resources, keyboard shortcuts, and regular expressions.
TopStyle Help & <b>Tutorial</b>tutorialsruby
This document provides a table of contents for the TopStyle Pro Help & Tutorial, which teaches how to use the TopStyle software for editing style sheets and HTML/XHTML documents. It lists over 50 sections that provide explanations and instructions for features like creating and opening files, editing styles, working with colors, previews, validation, site management, reports and customizing the software. The document was created by Giampaolo Bellavite from the online help provided with TopStyle version 3.11.
The Art Institute of Atlanta IMD 210 Fundamentals of Scripting <b>...</b>tutorialsruby
This document provides the course outline for IMD 210 Fundamentals of Scripting Languages at The Art Institute of Atlanta during the Spring 2005 quarter. The course focuses on integrating programming concepts with interface design using scripting languages like JavaScript and CSS. It will cover topics like DOM, CSS layout, JavaScript variables, conditionals, and events. Students will complete 4 assignments including redesigning existing websites, and there will be weekly quizzes, a midterm, and final exam. The course is worth 4 credits and meets once a week for class and lab.
This document provides the course outline for IMD 210 Fundamentals of Scripting Languages at The Art Institute of Atlanta during the Spring 2005 quarter. The course focuses on integrating programming concepts with interface design using scripting languages like JavaScript and CSS. It will cover topics like DOM, CSS layout, JavaScript variables, conditionals, and events. Students will complete 4 assignments including redesigning existing websites, and there will be weekly quizzes, a midterm, and final exam. The course is worth 4 credits and meets once a week for class and lab.
The group aims to bridge gaps between peer-to-peer database architectures and scaling multimedia information retrieval. They develop a probabilistic multimedia database system with abstraction layers for applications and researchers. They also research challenges of peer-to-peer networks for distributed data management. Both lines are supported by the MonetDB platform to exploit custom hardware and adaptive query optimization. The goal is a modular solution linking theoretical optimal solutions to application demands under resource limitations.
Standardization and Knowledge Transfer – INS0tutorialsruby
The group aims to bridge gaps between peer-to-peer database architectures and scaling multimedia information retrieval. They develop a probabilistic multimedia database system with abstraction layers and a flexible model. They also research challenges of peer-to-peer networks for distributed data management. Both lines are supported by the MonetDB platform to exploit custom hardware and adaptive query optimization. The goal is a modular solution linking theoretical optimal solutions to application demands under resource limitations.
This document provides an introduction to converting HTML documents to XHTML, including the basic syntax changes needed like making all tags lowercase and closing all tags. It provides examples of correct XHTML markup for different tags. It also explains the new DOCTYPE declaration and shows a sample well-formed XHTML document incorporating all the discussed changes. Resources for learning more about XHTML are listed at the end.
This document provides an introduction to converting HTML documents to XHTML, including the basic syntax changes needed like making all tags lowercase and closing all tags. It provides examples of correct XHTML markup for different tags. It also explains the new DOCTYPE declaration and shows a sample well-formed XHTML document incorporating all the discussed changes. Resources for learning more about XHTML are listed at the end.
XHTML is a markup language that provides structure and semantics to web pages. It is based on XML and is more strict than HTML. XHTML pages must have a document type definition, html and head tags, and a body where the visible content goes. Common XHTML tags include paragraphs, lists, links, images, and divisions to logically separate content. While XHTML provides structure, CSS is used to style pages and control visual presentation by defining rules for tags. CSS rules are defined in external style sheets to keep presentation separate from structure and content.
XHTML is a markup language that provides structure and semantics to web pages. It is based on XML and is more strict than HTML. XHTML pages must have a document type definition, html and head tags, and a body where the visible content goes. Common XHTML tags include paragraphs, lists, links, images, and divisions to logically separate content. While XHTML provides structure, CSS is used to style pages and control visual presentation through rules that target specific XHTML elements.
This document discusses how to create and use external cascading style sheets (CSS) in Dreamweaver. It provides steps to:
1. Open the CSS Styles tab in Dreamweaver and create a new external CSS stylesheet using a sample text style.
2. Save the stylesheet and link it to a new HTML page to style elements like headings, text sizes, and boxes.
3. Edit existing styles by selecting a tag in the CSS Styles panel and modifying properties directly, or by clicking the tag and using the pencil icon to edit in a window. This allows customizing styles globally across all linked pages.
This document provides an overview of how to create and use cascading style sheets (CSS) in Dreamweaver. It describes the different types of style sheets, including external and internal style sheets. It outlines the steps to create an external style sheet in Dreamweaver using the CSS Styles panel and provides instructions for linking the external style sheet to an HTML page. The document demonstrates how to experiment with predefined styles and how to edit, add, and delete styles in the CSS stylesheet.
This document appears to be a weekly update from an intro to computer science course. It includes summaries of classmates' demographics, comfort levels, and prior experience. It also discusses time spent on problem sets and recommends upcoming courses in CS51 and CS61. Finally, it recommends reading on TCP/IP, HTTP, XHTML, CSS, PHP, SQL and using the bulletin board for questions.
This document appears to be a weekly update from an intro to computer science course. It includes summaries of classmates' demographics, comfort levels, and prior experience. It also discusses time spent on problem sets and recommends upcoming courses in CS51 and CS61. Finally, it recommends reading on topics like TCP/IP, HTTP, XHTML, CSS, PHP, SQL and using bulletin boards, and includes images related to these topics.
The document discusses how to use Cascading Style Sheets (CSS) with Corvid Servlet Runtime templates to control formatting and layout. CSS allows separating design from content, making templates simpler and easier to maintain. It also enables adapting appearance for different devices. The document provides examples of using CSS classes to style template elements and explains how to set up a demo system using the included CSS and templates.
The document discusses how to use Cascading Style Sheets (CSS) with Corvid Servlet Runtime templates to control formatting and layout. CSS allows separating design from content, making templates simpler and easier to maintain. It also enables customization of appearance for different devices. The document provides examples of how to apply CSS classes and rules to Corvid template elements to control fonts, colors, positioning and more.
The document provides an introduction to CSS and how it works with HTML to control the presentation and styling of web page content. It explains basic CSS concepts like selectors, properties and values, and how CSS rules are used to target specific HTML elements and style them. Examples are given of common CSS properties and selectors and how they can be used to style elements and format the layout of web pages.
The document introduces CSS and how it works with HTML to separate content from presentation, allowing the styling of web pages through rules that target HTML elements. It explains CSS syntax and various selectors like type, class, ID, and descendant selectors. Examples are provided of how CSS can be used to style properties like color, font, padding, and layout of elements on a page.
Cascading Style Sheets (CSS) allow users to define how HTML elements are presented on a page. CSS enables changing the appearance and layout of an entire website by editing just one CSS file. CSS uses selectors to apply styles to HTML elements via properties and values. Styles can be defined internally in HTML or externally in CSS files. CSS can control text formatting, colors, spacing, positioning and more to achieve visual consistency across web pages.
Cascading Style Sheets (CSS) allow users to define how HTML elements are presented on a page. CSS enables changing the appearance and layout of an entire website by editing just one CSS file. CSS uses selectors to apply styles to HTML elements via properties and values. Styles can be defined internally in HTML or externally in CSS files. CSS can control text formatting, colors, spacing, positioning and more to achieve visual consistency across web pages.
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
GridMate - End to end testing is a critical piece to ensure quality and avoid...ThomasParaiso2
End to end testing is a critical piece to ensure quality and avoid regressions. In this session, we share our journey building an E2E testing pipeline for GridMate components (LWC and Aura) using Cypress, JSForce, FakerJS…
GraphSummit Singapore | The Future of Agility: Supercharging Digital Transfor...Neo4j
Leonard Jayamohan, Partner & Generative AI Lead, Deloitte
This keynote will reveal how Deloitte leverages Neo4j’s graph power for groundbreaking digital twin solutions, achieving a staggering 100x performance boost. Discover the essential role knowledge graphs play in successful generative AI implementations. Plus, get an exclusive look at an innovative Neo4j + Generative AI solution Deloitte is developing in-house.
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Enchancing adoption of Open Source Libraries. A case study on Albumentations.AIVladimir Iglovikov, Ph.D.
Presented by Vladimir Iglovikov:
- https://www.linkedin.com/in/iglovikov/
- https://x.com/viglovikov
- https://www.instagram.com/ternaus/
This presentation delves into the journey of Albumentations.ai, a highly successful open-source library for data augmentation.
Created out of a necessity for superior performance in Kaggle competitions, Albumentations has grown to become a widely used tool among data scientists and machine learning practitioners.
This case study covers various aspects, including:
People: The contributors and community that have supported Albumentations.
Metrics: The success indicators such as downloads, daily active users, GitHub stars, and financial contributions.
Challenges: The hurdles in monetizing open-source projects and measuring user engagement.
Development Practices: Best practices for creating, maintaining, and scaling open-source libraries, including code hygiene, CI/CD, and fast iteration.
Community Building: Strategies for making adoption easy, iterating quickly, and fostering a vibrant, engaged community.
Marketing: Both online and offline marketing tactics, focusing on real, impactful interactions and collaborations.
Mental Health: Maintaining balance and not feeling pressured by user demands.
Key insights include the importance of automation, making the adoption process seamless, and leveraging offline interactions for marketing. The presentation also emphasizes the need for continuous small improvements and building a friendly, inclusive community that contributes to the project's growth.
Vladimir Iglovikov brings his extensive experience as a Kaggle Grandmaster, ex-Staff ML Engineer at Lyft, sharing valuable lessons and practical advice for anyone looking to enhance the adoption of their open-source projects.
Explore more about Albumentations and join the community at:
GitHub: https://github.com/albumentations-team/albumentations
Website: https://albumentations.ai/
LinkedIn: https://www.linkedin.com/company/100504475
Twitter: https://x.com/albumentations
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
3. What Is Testing?
q Check that your code does what it's supposed to do.
q At varying levels of granularity.
q In varying environments.
q At various points in its development.
4. What Is Automated Testing?
q Programs to check other programs.
q As with any rote task, you let the computer do it.
x Humans will forget rote tests, computers will not
q Press a button and walk away.
x No human required (very important)
q Manually running tests is a waste of your time.
q Tests should run as close to instantaneous as possible
x so you won't have an excuse not to run them
x so you'll run them as often as possible
x Instant feedback
6. Why Test?
q no missing functionality
q no accidental functionality
q when your tests pass, you're done
7. More informative bug reports
q Better to get the diagnostic output of your tests than "It doesn't
work"
q Easily generated by end users
x "Run the tests and send me the output"
q Helps IMMENSELY with porting (this is why my code works on
VMS)
x You can often port code without ever using the machine you're
porting to
8. More More Reasons
q Most of the time spent on a project is debugging and bug fixing.
x Worse, it often comes at the end (hidden cost)
x "Oh, I'm 99% done, I just need to do some testing"
q Testing as you go will increase your development time, but
reduce debugging time.
x It will let you estimate more realistically
x Increased project visibility
x Reduced debug time once you get used to it
9. The Real Reason For Writing Tests
q Confidence.
x No fear of change
x No fear of lurking bugs
x No fear of breaking old things
x No fear that new things don't work
Ë Knowing when things don't work.
q So you can play and experiment without worry.
q Enable refactoring
10. Testing Is Laziness
q Take an O(n) amount of work and make it O(1)
x Instead of walking through the code by hand at each change
x Teach the computer to do that.
12. Textbook Testing
q Traditional testing philosophy says things like
Test all subroutines
Test all branches of all conditions
Test the boundary conditions of all inputs
...
q This is just big and scary and too much.
q We're lazy, and we think we can still be effective with much
less work.
13. XP Testing
q XP says to write your tests before you write your code.
x It's hard enough to get people to write tests at all.
x Changing their coding philosophy at the same time is worse.
q If you can do Test First, excellent.
q If you're not already testing, this is a chance to start some new
habits...
14. On Test-First Programming
q Think of it as coding to teeny, tiny, mini-iterations.
q Break each task into boolean expressions.
q Ask "What feature do I need next?"
x Test the smallest and most immediate element of the overall task.
x Take small steps!
15. The two test-first questions
q "How can I prove that this feature works?"
x Write the simplest test that will fail unless the feature works.
x The test must fail.
q "What is the least amount of code I can write to pass the test?"
x The simpler the test, the simpler the code you need.
x The test must now pass.
q This produces known good code and a comprehensive test
suite.
q Be sure to run the entire test suite after you implement a task.
q Don't be afraid of baby steps. That's the point.
16. Test Bugs
q Another good philosophy is to test bugs and new features.
q Every time you find a bug, write a test for it.
q Every time you add a new feature, write a test for it.
q In the process, you might test a few other related things.
q This is the simplest way to retrofit tests onto existing code.
17. Effects Of Testing Bugs
q This has pleasant effects:
x Slowly grows your test suite
x Focuses tests on the parts of the code which have the most bugs
q You're allowed to make mistakes, but ONLY ONCE. Never
twice.
q A disproportionate amount of bugs use the same logic.
x One test can catch lots of bugs
18. Knowing You're Done
t/Your-Code.t......ok
All tests successful.
q For once, your computer is telling you something good.
q Instant, positive feedback
19. There Is No Magic
q You may have seen this from h2xs.
######## We start with some black magic to print on failure.
# Change 1..1 below to 1..last_test_to_print .
# (It may become useful if the test is moved to ./t subdirec
BEGIN { $| = 1; print "1..1n"; }
END {print "not ok 1n" unless $loaded;}
use Foo;
$loaded = 1;
print "ok 1n";
######## End of black magic.
q Testing really isn't this frightening.
21. The Most Basic Perl Test Program
#!/usr/bin/perl -w
print "1..1n";
print 1 + 1 == 2 ? "ok 1n" : "not ok 1n";
q Since 1 + 1 is 2, this prints:
1..1
ok 1
x "1..1" I'm going to run one test.
x "ok 1" The first test passed.
22. Perl's Testing Protocol
q There are two parts to running a test in Perl.
x Your test
x Test::Harness
q The output of your test is piped to Test::Harness.
q Test::Harness interprets your output and reports.
$ perl -MTest::Harness -wle 'runtests @ARGV' contrived.t
contrived....ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.02 cusr + 0.02 csys
23. There's TMTOWTDI and there's this...
q Here's some of the many ways people write their tests:
x t/op/sysio.t
print 'not ' unless (syswrite(O, $a, 2) == 2);
print "ok 20n";
x ext/Cwd/t/cwd.t
print +($getcwd eq $start ? "" : "not "), "ok 4n";
x t/pod/plainer.t
unless( $returned eq $expected ) {
print map { s/^/#/mg; $_; }
map {+$_} # to avoid readonly values
"EXPECTED:n", $expected, "GOT:n", $returned;
print "not ";
}
printf "ok %dn", ++$test;
q Maintenance nightmare.
24. I'm ok, you're ok
#!/usr/bin/perl -w
use Test::Simple tests => 1;
ok( 1 + 1 == 2 );
q "ok" is the backbone of Perl testing.
x If the expression is true, the test pass.
x False, it fails.
q Every conceivable test can be performed just using ok().
25. YOU FAILED!!!
#!/usr/bin/perl -w
use Test::Simple tests => 2;
ok( 1 + 1 == 2 );
ok( 2 + 2 == 5 );
q from that comes:
1..2
ok 1
not ok 2
# Failed test (contrived.t at line 5)
# Looks like you failed 1 tests of 2.
x "1..2" I'm going to run two tests.
x "ok 1" The first test passed.
x "not ok 2" The second test failed.
x Some helpful commentary from Test::Simple
26. Date::ICal
q We're going to write some tests for Date::ICal.
x It's real code.
x It's sufficiently complex.
x Everyone understands dates.
Ë Some people even have them.
27. Where To Start?
q This is the hardest part.
q Retrofitting a test suite onto old code sucks.
x Marching through the testing swamps.
q Write tests from the start and your life will be easier.
q In any event, begin at the beginning.
28. new()
q Since Date::ICal is OO, the beginning is when you make an
object.
x (white-lie: the beginning is when you load the module)
#!/usr/bin/perl -w
use Test::Simple tests => 2;
use Date::ICal;
my $ical = Date::ICal->new; # make an object
ok( defined $ical ); # check we got something
ok( $ical->isa('Date::ICal') ); # and it's the right class
q This produces:
1..2
ok 1
ok 2
q This is your first useful test.
29. Names
q "ok 2" isn't terribly descriptive.
x what if you have 102 tests, what did #64 do?
q Each test can be given a little description.
ok( defined $ical, 'new() returned something' );
ok( $ical->isa('Date::ICal'), " and it's the right class" )
q This outputs
1..2
ok 1 - new() returned something
ok 2 - and it's the right class
30. What's In A Name
q Two views on names.
x A name is a descriptive tag so you can track the test output back to
the code which produced it. (the original purpose)
x A name is a short description of what was tested.
q There's a subtle difference.
q Don't pull your hair out over it.
x More importantly, don't pull other people's hair out over it.
31. Test The Manual
q Simplest way to build up a test suite is to just test what the
manual says it does.
x Also a good way to find mistakes/omissions in the docs.
x You can take this five steps further and put the tests IN the
manual. Test::Inline, later.
q If the docs are well written, they should cover usage of your
code.
x You do have docs, right?
32. SYNOPSIS
q A good place to start.
x A broad overview of the whole system
q Here's a piece of Date::ICal's SYNOPSIS.
SYNOPSIS
use Date::ICal;
$ical = Date::ICal->new( year => 1964, month => 10, day =
hour => 16, min => 12, sec => 47, tz => '0530' );
$hour = $ical->hour;
$year = $ical->year;
q Oddly enough, there is a bug in this.
33. SYNOPSIS test
use Test::Simple tests => 8;
use Date::ICal;
$ical = Date::ICal->new(
year => 1964, month => 10, day => 16, hour => 16,
min => 12, sec => 47, tz => '0530' );
ok( defined $ical, 'new() returned something' );
ok( $ical->isa('Date::ICal'), " and it's the right class" )
ok( $ical->sec == 47, ' sec()' );
ok( $ical->min == 42, ' min()' );
ok( $ical->hour == 10, ' hour()' );
ok( $ical->day == 16, ' day()' );
ok( $ical->month == 10, ' month()' );
ok( $ical->year == 1964, ' year()' );
34. SYNOPSIS results
1..8
ok 1 - new() returned something
ok 2 - and it's the right class
ok 3 - sec()
not ok 4 - min()
# Failed test (ical.t at line 14)
not ok 5 - hour()
# Failed test (ical.t at line 15)
ok 6 - day()
ok 7 - month()
ok 8 - year()
# Looks like you failed 2 tests of 8.
q Whoops, failures!
q We know what and where it failed, but not much else.
q How do you find out more?
x Throw in print statements
x Run in the debugger.
q That sounds like work.
35. Test::More
q Test::Simple is deliberately limited to one function.
q Test::More does everything Test::Simple does.
x You can literally s/use Test::Simple/use Test::More/
q It provides more informative ways to say "ok".
36. is() you is() or is() you isnt() my $baby;
q Test::More's is() function:
x declares that something is supposed to be something else
x "Is this, that?"
is( $this, $that );
# From
ok( $ical->day == 16, ' day()' );
# To
is( $ical->day, 16, ' day()' );
37. ok() to is()
q Here's the test with ok() replaced with is() appropriately.
use Test::More tests => 8;
use Date::ICal;
$ical = Date::ICal->new(
year => 1964, month => 10, day => 16, hour => 16,
min => 12, sec => 47, tz => '+0530' );
ok( defined $ical, 'new() returned something' );
ok( $ical->isa('Date::ICal'), " and it's the right class" )
is( $ical->sec, 47, ' sec()' );
is( $ical->min, 42, ' min()' );
is( $ical->hour, 10, ' hour()' );
is( $ical->day, 16, ' day()' );
is( $ical->month, 10, ' month()' );
is( $ical->year, 1964, ' year()' );
q "Is $ical->sec, 47?"
q "Is $ical->min, 12?"
38. Diagnostic Output
1..8
ok 1 - new() returned something
ok 2 - and it's the right class
ok 3 - sec()
not ok 4 - min()
# Failed test (- at line 13)
# got: '12'
# expected: '42'
not ok 5 - hour()
# Failed test (- at line 14)
# got: '21'
# expected: '10'
ok 6 - day()
ok 7 - month()
ok 8 - year()
# Looks like you failed 2 tests of 8.
q $ical->min returned 12 instead of 42.
q $ical->hour returned 21 instead of 10.
39. Interpreting The Results
q Turns out, there is no 'tz' argument to new()!
x And it didn't warn us about bad arguments
q The real argument is 'offset'
x So the synopsis is wrong.
x This is a real bug I found while writing this
q Damn those tests.
40. When to use is()
q Use instead of ok() when you're testing "this equals that".
x Yes, there is an isnt() and isn't().
q is() does a string comparison which 99.99% of the time comes
out right.
x cmp_ok() exists to test with specific comparison operators
41. Tests Are Sometimes Wrong
q The previous example was supposed to be highly contrived to
illustrate that tests are sometimes wrong.
q When investigating a test failure, look at both the code and the
test.
q There's a fine line of trusting your testing code.
x Too much trust, and you'll be chasing phantoms.
x Too little trust, and you'll be changing your tests to cover up bugs.
42. How Can I Be Sure The Test Is Right?
q Write the test
q Run it and make sure the new test fails
q Add the new feature / fix the bug
q Run the test and make sure the new test passes.
q Some development systems, such as Aegis, can enforce this
process.
q It's difficult to do this when writing tests for existing code.
x Another reason to test as you go
43. Version Control and Testing
q VC & testing work well.
x Run the tests, make sure they pass
x Make sure everything is checked in.
x Write tests for the bug / feature.
Ë Make sure they fail.
x Fix your bug / write your feature
x Run the tests.
Ë If they pass, commit. You're done.
Ë If they fail, look at the diff. The problem is revealed by that change.
q The smaller the change, the better this works.
q You are using version control, right?
44. Testing vs Brooks's Law
q Tests catch damage done by a new programmer immediately
q Easier for other developers to help you
x They can pre-test their patches.
x Even if you write perfect code, the rest of us don't.
45. Testing Lots Of Values
q Date handling code is notorious for magic dates that cause
problems
x 1970, 2038, 1904, 10,000. Leap years. Daylight savings.
q So we want to repeat sets of tests with different values.
46. It's Just Programming
use Test::More tests => 32;
use Date::ICal;
my %ICal_Dates = (
'19971024T120000' => # from the docs.
[ 1997, 10, 24, 12, 0, 0 ],
'20390123T232832' => # after the Unix epoch
[ 2039, 1, 23, 23, 28, 32 ],
'19671225T000000' => # before the Unix epoch
[ 1967, 12, 25, 0, 0, 0 ],
'18990505T232323' => # before the MacOS epoch
[ 1899, 5, 5, 23, 23, 23 ],
);
while( my($ical_str, $expect) = each %ICal_Dates ) {
my $ical = Date::ICal->new( ical => $ical_str, offset => 0 )
ok( defined $ical, "new(ical => '$ical_str')" );
ok( $ical->isa('Date::ICal'), " and it's the right class" )
is( $ical->year, $expect->[0], ' year()' );
is( $ical->month, $expect->[1], ' month()' );
is( $ical->day, $expect->[2], ' day()' );
is( $ical->hour, $expect->[3], ' hour()' );
is( $ical->min, $expect->[4], ' min()' );
is( $ical->sec, $expect->[5], ' sec()' );
}
47. The Good News
q If you can write good code, you can learn to write good tests.
q Just a while loop.
q Easy to throw in more dates.
48. The Bad News
q You have to keep adjusting the # of tests when you add a date.
x use Test::More tests => ##;
q There are some tricks:
# For each date, we run 8 tests.
use Test::More tests => keys %ICal_Dates * 8;
q There's also 'no_plan':
use Test::More 'no_plan';
49. Plan? There Ain't No Plan!
q The plan exists for protection against:
x The test dying
x Accidentally not printing tests to STDOUT
x Exiting early
q The first two have other protections, and the third will shortly.
x So the plan isn't as useful as it used to be
q Newer versions of Test::Harness allow the plan to be at the
end:
ok 1
ok 2
ok 3
1..3
q This allows Test::More to count your tests for you.
x You have to upgrade Test::Harness for this to work.
50. Boundary tests
q Almost bad input
q Bad input
q No input
q Lots of input
q Input that revealed a bug
51. Bad Input Can Do Bad Things
q Garbage in / Error out
x graceful exceptions, not perl errors
x helpful warnings, not uninitialized value warnings
q Make sure bad input causes predictable, graceful failure.
52. Basic bad input example
use Test::More tests => 2;
local $!;
ok( !open(FILE, "I_dont_exist"), 'non-existent file' );
isnt( $!, 0, ' $! set' );
q Note, the exact value of $! is unpredictable.
53. Tests with warnings
q Test::More used to have a problem testing undefined values
use Test::More tests => 1;
is( undef, undef, 'undef is undef' );
q The test will pass, but there would be warnings.
x The user will see them, but the test will not.
q There's a whole bunch of these in Test-Simple/t/undef.t
54. Catching Warnings
q Use $SIG{__WARN__}.
my $warnings = '';
local $SIG{__WARN__} = sub { $warnings . join '', @_ };
use Test::More tests => 2;
is( undef, undef, 'undef is undef' );
is( $warnings, '', ' no warnings' );
q Use the same technique to check for expected warnings.
55. Dealing With Death
q Use eval BLOCK.
local $@;
eval {
croak "Wibble";
};
like( $@, qr/^Wibble/ );
q Use the same technique to check that things didn't die.
x Useful for past bugs where certain inputs would cause a fatal error.
56. Acceptance, Regression, Unit, Functional...
q Same thing, just a matter of timing.
q Unit: Detailed tests of individual parts
x Unit tests are easy(er)
x So we think of the rest in terms of unit tests
q Functional: Tests of your API
x Blackbox unit tests
q Integration: Testing that the pieces work together
x Just unit testing bigger units
q Acceptance: Tests defining your requirements
x Customer driven unit tests
q Regression: Tests for backwards compatibility
x Old tests never die, they just become regression tests
q All can be done with the same techniques
57. Blackbox vs Glassbox
q No, they're not window managers.
q Blackbox tests use only the public, documented API.
x No cheating
x You have to forget how the code is implemented
x More closely approximates real world usage
x Immune from internal changes
x Often forces you to make the public API more flexible
q Glassbox tests can use whatever you want.
x Cheat, steal, lie, violate encapsulation
x Often necessary to test certain 'untestable' parts
x May be broken by internal changes, undermines the test suite.
q Blackbox is preferred where possible, glassbox is sometimes
necessary.
x Sometimes you can just peek inside the box.
58. Test::More toys
q Test::More has 13 ways to say ok.
x It also has a wonderful man page.
q Here's some of the most common.
59. like()
q Next to is() and ok(), you'll be using like() the most.
like( $this, qr/that/ );
q This is the same as:
ok( $this =~ /that/ );
q It has nicer diagnostics:
not ok 1
# Failed test (contrived.t at line 2)
# 'wibble'
# doesn't match '(?-xism:woof)'
q Because qr// was added in 5.005, it understands a string that
looks like a regex for older perls.
like( $this, '/that/' );
q There is an unlike() which is the !~ version.
60. isa_ok()
q We've been doing this a lot.
ok( defined $ical, "new(ical => '$ical_str')" );
ok( $ical->isa('Date::ICal'), " and it's the right class" )
q You do this so much in OO code, there's a special function.
isa_ok( $ical, 'Date::ICal' );
q It works on references, too.
isa_ok( $foo, 'ARRAY' ); # is $foo an array ref?
q It also has nice diagnostics.
not ok 1 - The object isa Date::ICal
# Failed test (- at line 2)
# The object isn't a 'Date::ICal' it's a 'ARRAY'
61. can_ok()
q A test for $obj->can($some_method)
ok( $obj->can('foo'), 'foo() method inherited' );
q Simple but useful test can be like:
# Does the Foo class have these methods?
can_ok( 'Foo', qw(this that whatever wibble) );
x Might seem silly, but can catch stupid mistakes like forgetting a "=cut"
q Takes an object or a class.
q Also useful for checking your functions are exported
use Text::Soundex;
can_ok(__PACKAGE__, 'soundex');
62. use_ok()
q The real first thing you test is if the module loaded.
use Test::More tests => 1;
BEGIN { use_ok( 'Date::ICal' ); }
q Has to be inside a BEGIN block to act like a real 'use'.
q Remember the black magic? That's what it was doing.
63. is_deeply()
q For comparing complex data structures
x Hashes, lists, hash of lists of hashes of lists of scalar references...
my %expect = ( this => 42, that => [qw(1 2 3)] );
my %got = some_function();
is_deeply( %got, %expect );
q Will show you where the two structures start to diverge
not ok 1
# Failed test (- at line 2)
# Structures begin differing at:
# $got->{that}[2] = '3'
# $expected->{that}[2] = Does not exist
q In CS this is really a "shallow comparison" and is() is "deep".
x So the name is wrong because Schwern failed CS.
q A stopgap measure
x Currently doesn't handle circular structures (patches welcome)
q Waiting for someone to step up to the plate and write Test::Set
64. diag()
q Test::More's functions are pretty good about providing
diagnostics.
q Sometimes you need more...
q diag() lets you display whatever diagnostic information you
want.
x Guaranteed not to interfere with Test::Harness
x Not a test function
x Will not display inside a TODO block
q Useful for giving suggestions about tricky failures
65. Odd User Reactions
q Sometimes users react rather oddly to tests.
x won't report failures
x will react to failures as if the test caused the bug!
x will report "the tests failed" and leave off all the diagnostics
x won't run the tests at all
66. Getting People to RUN Your Tests
q Once you've gotten people writing tests...
q ...your next problem is getting them to RUN them
67. Make It Simple
q Preferably ONE command.
x no user interaction (or smart defaults)
x 'make test'
x 'quicktest' CVS integration.
68. Test On Commit
q Make running the tests part of your commit policy
x Automate with CVS commit actions (CVSROOT/modules)
x Use a system such as Aegis
69. Daily Smoke Test
q Run the whole battery of tests against the latest code every
day, automatically
x CPAN::Smoke is one example
70. Test Before Release
q Automatically run tests as part of your release process.
x 'make disttest'
x your release process is automated, right?
71. Testing Is Eating Your Own Dog Food
q It forces you to use your own API.
q Code that's hard to test may be hard to use.
q This often makes your API more flexible.
x Tends to get rid of constants and assumptions
72. 'make test'
schwern@blackrider:~/src/devel/File-chdir$ make test
PERL_DL_NONLAZY=1 /usr/local/bin/perl5.6.1 -Iblib/arch
-Iblib/lib -I/usr/local/perl5.6.1/lib/5.6.1/ppc-linux-64int
-I/usr/local/perl5.6.1/lib/5.6.1 -e
'use Test::Harness qw(&runtests $verbose); $verbose=0;
runtests @ARGV;' t/*.t
t/array.............ok
t/chdir.............ok
t/var...............ok
All tests successful.
Files=3, Tests=48, 2 wallclock secs
( 1.71 cusr + 0.38 csys = 2.09 CPU)
q When you run 'make test' on a CPAN module, you're using:
ExtUtils::MakeMaker
Test::Harness
your test
73. What in the hell is all that mess?
PERL_DL_NONLAZY=1
q magic to force XS code to strictly check shared libraries
-Iblib/lib -Iblib/lib
q Changes @INC to use the module you're about to install
-I/usr/local/perl5.6.1/lib/5.6.1/ppc-linux-64int ...
q Mistake. Code specific for testing Perl itself that leaked out.
q Causes problems with core modules on CPAN.
q Fixed in latest versions of MakeMaker.
74. The mess continued...
-e 'use Test::Harness qw(&runtests $verbose);
q import runtests and $verbose
$verbose=0
q This is really $verbose=$(TEST_VERBOSE)
runtests @ARGV;' t/*.t
q Pass in all your tests to Test::Harness::runtests()
75. Still more mess...
t/array.............ok
t/chdir.............ok
t/var...............ok
q Your tests are all ok
All tests successful.
q It's Miller Time.
Files=3, Tests=48, 2 wallclock secs
( 1.71 cusr + 0.38 csys = 2.09 CPU)
q Benchmark of how long your tests took to run. May go away.
76. New MakeMaker Is A Little Different
$ make test
PERL_DL_NONLAZY=1 /usr/local/bin/perl
"-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/array....ok
t/chdir....ok
t/var......ok
All tests successful.
Files=3, Tests=48, 3 wallclock secs
( 2.27 cusr + 0.48 csys = 2.75 CPU)
q The -I$(PERL_LIB) -I$(PERL_ARCH) mistake is gone
q The hanging Test::Harness wires have been put away
q Mostly done for non-Unix platforms.
77. test.pl caveat
q Some modules put tests in test.pl.
q Do not do that.
q 'make test' does not parse the output which means...
x 'make test' won't exit with non-zero on failure.
x Things like the CPAN shell won't know there was a failure.
x Historical accident, MakeMaker predates Test::Harness.
78. Testing and Perl versions
q Test::Simple/More will be in 5.8.0.
q Test.pm was put in 5.4.5.
q Test::Harness has been around so long nobody remembers
who wrote it.
x pre-5.6.1 will not support TODO tests or no_plan.
q They're all available from CPAN.
q They all work back to 5.4.0.
q They all work on every platform.
79. Testing, CPAN Modules, PREREQ_PM
q Some people worry about having too many prereqs on their
CPAN modules
x Don't want to add prereqs on testing modules
q A prereq of Test::More in turn prereqs & upgrades
Test::Harness.
q Even though Test::More isn't yet in core, it's already widely
installed.
Acme::ComeFrom, Acme::Magpie, Acme::Time::Asparagus,
Acme::USIG, Acme::Your, Alzabo, Apache::ConfigParser,
Apache::DefaultCharset, Apache::GuessCharset, Apache::RSS,
Apache::Session::CacheAny,
Apache::Session::Generate::ModUniqueId,
Apache::Session::Generate::ModUsertrack,
Apache::Session::PHP, Apache::Session::SQLite,
Apache::Singleton, Apache::StickyQuery, App::Info,
Archive::Any, Astro::Funtools::Parse, Attribute::Profiles,
Attribute::Protected, Attribute::Unimplemented, CPAN,
Business::Tax::Vat, Cache::Mmap, Carp::Assert, CDDB::File,
CGI::Application, CGI::FormMagick, CGI::Untaint,
CGI::Untaint::creditcard, CGI::Untaint::email,
CGI::Untaint::uk_postcode, Class::DBI,
81. Everybody's Depending on Us!
Mail::Address::Tagged, Mail::ListDetector,
Mail::ListDetector::Detector::Fml, MARC::Record,
Math::Currency, Module::CoreList, Module::InstalledVersion,
SPOPS, Net::DNS, Net::DNS::Zonefile, Net::ICal,
Net::IDN::Nameprep, Net::IP::Match, Net::Services,
Net::Starnet::DataAccounting, Net::Telnet::Cisco,
OutNet::BBS, PerlPoint::Package, PHP::Session,
Pod::Coverage, Test::Inline,
POE::Component::IKC::ReallySimple, POE::Component::RSS,
POE::Component::SubWrapper, POE::Session::Cascading,
Proc::InvokeEditor, Regexp::English, Regexp::Network,
Spreadsheet::ParseExcel::Simple, Storable, Sub::Context,
Sub::Parameters, Term::Cap, Term::TtyRec, Test::Class,
Test::Exception, Test::Mail, CGI::Application, Text::Quote,
Text::WikiFormat, Tie::Array::Iterable, Tie::Hash::Approx,
uny2k, WWW::Automate, WWW::Baseball::NPB, WWW::Page::Author,
WWW::Page::Host, WWW::Page::Modified, WWW::Search,
XML::Filter::BufferText, XML::SAX::Writer, XML::XPath::Simpl
XML::XSLT, XTM, XTM::slides
q So the prerequisite will likely already be resolved.
q Brought to you by Schwern Of Borg.
82. t/lib trick
q If you still don't want to have prerequisites on testing modules
x Copy Test/Builder.pm & Test/More.pm into t/lib/
x Slap a "use lib 't/lib'" on your tests
x distribute the whole thing
q Who does this?
x CGI, CPANPLUS, MakeMaker, parrot, Test::Harness
q Caveats
x You'll be adding to Test::More's takeover of search.cpan.org
x Adds 18K to your tarball.
x Can't use TODO or no_plan.
83. Make the GUI layer thin
q GUIs, CGI programs, etc... are hard to test.
q Make the problem as small as possible.
x Separate the form from the functionality.
x Put as much code into format agnostic libraries as possible
x Large, stand-alone programs (especially CGIs) ring alarm bells.
q You might wind up with a small amount that still needs to be
tested by hand.
x At least you don't have to test the whole thing by hand.
84. Testing Web Stuff
q WWW::Automate is your friend.
x LWP with lots of help.
x Easily deals with forms
x "Click" on buttons
x Follow links
x Has a "back" button
q Makes simulating a real web site user easier.
85. Domain Specific Test Libraries
q WWW::Automate
x Technically not a test library, but sooooo useful
q Test::Exception
q Test::Differences
x Testing large blocks of text and complicated structures
q Test::Unit
x Straight XUnit port to Perl
x Great for those used to JUnit & PyUnit
q Test::Class
x XUnit, but adapted to Perl
x Inherited tests
q Test::MockObject
q Test::Inline
x Embed tests in your documentation
q Test::Mail
86. Test::Builder
q Usually you want Test::More's general functions + domain
specific ones.
x Unfortunately, sometimes test libraries don't play well together
x Who owns the test counter?
x Who prints the plan?
q Test::Builder is a single backend to solve that problem.
x Singleton object to handle the plan and the counter
x Test::More-like methods you can write wrappers around
q Test libraries built on Test::Builder will work together.
Test::Exception, Test::Class, Test::MockObject,
Test::Inline, Test::Mail, Test::More, Test::Simple
q Attend "Writing A Test Library" for more information
87. Passing Tests Should PASS
q One must trust their test suite, else it will be ignored.
q When it fails, it should indicate a real problem.
q "Expected failures" sap that trust.
x "Oh, don't worry, that test always fails on Redhat 6.2"
x If a failure sometimes isn't really a failure, when do you know a real
failure?
q "Expected failures" make test automation impossible.
x Programs don't know "well, the test failed but it really passed"
x Joe CPAN module installer also doesn't know that.
q Get your test suite at 100% and keep it there.
x That's worth saying again.
q STAY AT 100% PASSING!
88. Failure Is An Option
q There are three varieties of test failure, and several solutions.
x A failure indicating a mistake/bad assumption in the test suite.
Ë You fix it.
x A real failure indicating a bug or missing feature.
Ë You fix it, or...
Ë You put off fixing it and...
Ë comment out the test (blech) or...
Ë declare it "TODO"
x A failure due to an assumption about the environment.
Ë You can't fix it, so you "skip" it.
89. It'll Never Work
q Sometimes, a test just doesn't make sense in certain
environments.
q Some examples...
x Features which require a certain version of perl
x Features which require perl configured a certain way (ex. threads)
x Features which are platform specific
x Features which require optional modules
90. Skipping Tests
q Let's assume we have a test for an HTML generator.
q Let's also assume that if we have HTML::Lint, we want to lint
the generated code.
require HTML::Lint;
my $lint = HTML::Lint->new;
isa_ok( $lint, 'HTML::Lint' );
$lint->parse( $some_html );
is( $lint->errors, 0, 'No errors found in HTML' );
q Since HTML::Lint is optional, this test will fail if you don't have
it.
x But it's not a real failure, else HTML::Lint isn't really optional.
x So the user shouldn't hear about it.
91. # SKIP
q You can explicitly skip a set of tests rather than run them.
1..2
ok 1
ok 2 # SKIP no beer
x Test #1 passed.
x Test #2 was skipped because there is no beer.
q A skipped test means the test was never run.
92. SKIP: block
q Test::More can cause an entire block of code not to run at all.
SKIP: {
eval { require HTML::Lint };
skip "HTML::Lint not installed", 2 if $@;
my $lint = new HTML::Lint;
isa_ok( $lint, "HTML::Lint" );
$lint->parse( $html );
is( $lint->errors, 0, "No errors found in HTML" );
}
x if we don't have HTML::Lint, the skip() function is run.
x skip() prevents anything further in the SKIP block to be run.
x the number indicates how many tests you would have run.
q The appropriate number of 'ok's will be output.
ok 23 # SKIP HTML::Lint not installed
ok 24 # SKIP HTML::Lint not installed
93. skipall
q In some cases you want to skip a whole test file.
use Test::More;
if( $^O eq 'MSWin32' ) {
plan tests => 42;
}
else {
plan skip_all => 'Win32 specific test';
}
q Test::More will exit at the skip_all.
q On non-Win32, the output will be:
1..0 # skip Win32 specific test
q Test::Harness will interpret this as a skipped test.
94. Procrastination Codified
q It's good to write the test before you add a new feature.
q It's good to write a test as soon as you receive a bug report.
q It's bad to release code with failing tests.
q This would seem to be a contradiction.
x Either you fix all your bugs and add all your features immediately
x Or you comment out your failing tests.
q Option #3, for the professionally lazy:
x Declare your failing tests to be "todo"
q This allows one to build a test suite without having to fix all the
bugs you find right away.
95. TODO Test
TODO: {
local $TODO = 'URI::Geller not quite working';
my $card = 'Eight of clubs';
is( URI::Geller->your_card, $card, 'Is this your card?' );
my $spoon;
URI::Geller->bend($spoon);
is( $spoon, 'bent', 'Spoon bending' );
}
q Output will be something like:
not ok 23 - Is this your card
# TODO URI::Geller not quite working
not ok 24 - Spoon bending
# TODO URI::Geller not quite working
96. Automated TODO List
q TODO reverses the sense of the test
x 'not ok' will be treated as a quiet success
x 'ok' Test::Harness will warn you of an "unexpected success"
q It's a TODO list
x Write your tests before your feature/bug fix
x Each 'unexpected success' is an item off your todo list
x Remove the TODO wrapper
q You can release at any point and not have to cull your test
suite
q Keeps users from seeing "expected failures"
q Each open bug can have a test.
x Sometimes bugs get accidentally fixed
97. Keep Test Scripts Small
q Many testing questions start with
x "I've got this test script with 1400 tests..."
q Big tests are
x Hard to maintain
x Hard to decouple
x Hard to read
x Take a long time to run
x Have all the same problems as big subroutines
q Keep them small & focused.
x One function or set of functions per script
x One aspect per script
x Put complicated tests in their own script
x Put slow tests in their own script
q Test::Simple/More's tests are a good example
98. Big FTP/XML program example
q Common testing problem. You have a big program which...
x Downloads an XML file via FTP
x Parses the XML
x Generates HTML
q How do you test that?
99. Programs Are Hard, Libraries Are Easy
q The smaller the piece, the better.
q The more flexible the piece, the better.
q The more hooks into the guts, the better.
x Libraries of functions can have small, flexible pieces.
x Programs are, by definition, monolithic.
q Extract pieces out of your program and put it into a library
x Then test the library
x Side-benefit, you'll have improved your code
q Take the FTP, XML parsing and HTML generation code out of
the program.
100. Separate Form And Functionality
q HTML is hard to test
x It changes a lot
x It's hard to parse
q Instead of going from XML straight to HTML
q ...go from XML -> agnostic format -> HTML
x Test the XML -> agnostic part
x Test the agnostic -> HTML part
q Much easier to test when only one of the input/output pair is
formatted.
q ...and you'll have improved the flexibility of your code.
101. Mock Code
q Sometimes you just can't run a piece of code in a test
x Maybe there's no network connection
x Maybe the test is destructive (system("/sbin/shutdown now"))
q Going to the extreme edge of glassbox testing, replacing code
for testing
102. System call / Power manager example
q Say you have to test a power management daemon
q One of the things it does is puts the computer to sleep
q How do you test that?
sub should_i_sleep {
my($power_remaining) = @_;
system("/sbin/snooze") if $power_remaining < $Min_Power;
return 1;
}
103. First, Isolate The Untestable Part
sub should_i_sleep {
my($power_remaining) = @_;
snooze if $power_remaining < $Min_Power;
return 1;
}
sub snooze {
system("/sbin/snooze");
}
q Test snooze() by hand once.
x It's small, so you can get away with it
104. Then, Replace The Untestable Part
{
my @snooze_args = ();
my $snooze_called = 0;
local *Power::Manager::snooze = sub {
$snooze_called++;
@snooze_args = @_; # trap the arguments
return 0; # simulate successful system call
};
should_i_sleep($Min_Power - 1);
is( $snooze_called, 1, 'snooze called once' );
is( @snooze_args, 0, ' called properly' );
}
q Check that it was called.
q Check that it got the right arguments
q By changing the return value to non-zero we can simulate a
failure.
q Very, very powerful technique.
105. Forcing Failure
q How will your program react if, say, the database connection
fails?
use DBI;
{
local *DBI::connect = sub {
return 0;
};
...test for graceful failure here...
}
...test for graceful recovery here...
106. He's Your Dog, Charlie Brown
q Don't leave testing for the QA guys
x too much delay
x too much animosity
q You know your code, you can test it
x and you can fix it
x and you wrote it, so it's your bug :P