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.
Unit testing and test-driven development are practices that makes it easy and efficient to create well-structured and well-working code. However, many software projects didn't create unit tests from the beginning.
In this presentation I will show a test automation strategy that works well for legacy code, and how to implement such a strategy on a project. The strategy focuses on characterization tests and refactoring, and the slides contain a detailed example of how to carry through a major refactoring in many tiny steps
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.
The document is a walkthrough of using test-driven development (TDD) to solve an encryption problem. It begins by setting up test and source code files. Tests are written based on examples from the problem. Minimal code is written to pass each test. Refactoring improves the code while maintaining passing tests. The implementation is generalized through many small iterative changes. Edge cases are addressed, like when the encryption grid is too small. The completed solution passes all tests.
The document describes an introductory training course on PHPUnit testing. It discusses installing PHPUnit and getting started with writing tests. Specifically, it shows how to write a first test case to test a Game_Grid class by creating a GridTest.php file. It fails initially since the class doesn't exist yet. The test is then made to pass by creating the Grid class file. The document also discusses bootstrapping tests by creating a Bootstrap.php file to autoload classes so requires aren't needed in each test.
The document describes the Test Anything Protocol (TAP), which is a standard format for representing test results. It discusses the structure and grammar of TAP, provides examples of TAP output, and notes that TAP is used by many testing frameworks across multiple programming languages. The document is intended to provide an overview of TAP for an audience that includes discussing how TAP is used with continuous integration systems.
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 and test-driven development are practices that makes it easy and efficient to create well-structured and well-working code. However, many software projects didn't create unit tests from the beginning.
In this presentation I will show a test automation strategy that works well for legacy code, and how to implement such a strategy on a project. The strategy focuses on characterization tests and refactoring, and the slides contain a detailed example of how to carry through a major refactoring in many tiny steps
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.
The document is a walkthrough of using test-driven development (TDD) to solve an encryption problem. It begins by setting up test and source code files. Tests are written based on examples from the problem. Minimal code is written to pass each test. Refactoring improves the code while maintaining passing tests. The implementation is generalized through many small iterative changes. Edge cases are addressed, like when the encryption grid is too small. The completed solution passes all tests.
The document describes an introductory training course on PHPUnit testing. It discusses installing PHPUnit and getting started with writing tests. Specifically, it shows how to write a first test case to test a Game_Grid class by creating a GridTest.php file. It fails initially since the class doesn't exist yet. The test is then made to pass by creating the Grid class file. The document also discusses bootstrapping tests by creating a Bootstrap.php file to autoload classes so requires aren't needed in each test.
The document describes the Test Anything Protocol (TAP), which is a standard format for representing test results. It discusses the structure and grammar of TAP, provides examples of TAP output, and notes that TAP is used by many testing frameworks across multiple programming languages. The document is intended to provide an overview of TAP for an audience that includes discussing how TAP is used with continuous integration systems.
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.
TDD and Simple Design Workshop - Session 1 - March 2019Paulo Clavijo
The document discusses test-driven development (TDD) and simple design. It introduces TDD and some of its core practices, including test-driven development, simple design, refactoring, and pair programming. It provides an agenda for a workshop that will cover these topics over three sessions, including extreme programming (XP), the four elements of simple design, test doubles, outside-in TDD, and SOLID principles. The workshop aims to communicate best practices for using technical practices to succeed with agile development.
Refactoring legacy code driven by tests - ENGLuca Minudel
re you working on code poorly designed or on legacy code that’s hard to test? And you cannot refactor it because there are no tests?
During this Coding Dojo you’ll be assigned a coding challenge in Java, C#, Ruby, JavaScript or Python. You will face the challenge of improving the design and refactoring existing code in order to make it testable and to write unit tests.
We will discuss SOLID principles, the relation between design and TDD, and how this applies to your solution.
Reading list:
Growing Object-Oriented Software, Guided by Tests; Steve Freeman, Nat Pryce
Test Driven Development: By Example; Kent Beck
Working Effectively with Legacy; Michael Feathers
Agile Software Development, Principles, Patterns, and Practices; Robert C. Martin (C++, Java)
Agile Principles, Patterns, and Practices in C#; Robert C. Martin (C#)
Mockito 2.x Migration - Droidcon UK 2018Hazem Saleh
Mockito 2.x solves many problems that most of the Android developers were having in their tests in Mockito 1.x. But what if you are having today large tests written in Mockito 1.x and PowerMock, will it be an easy task to migrate?
Unfortunately, it is not a straightforward task since Mockito 2 is not fully compatible with the old behaviour of Mockito 1.x. Adding to this complexity, If you are having PowerMock in your old tests, then you will have to face another dimension of complexity since most of PowerMock’s versions are having integration issues with Mockito 2.x.
This session goes through the tips and tricks that you need to consider in order to migrate to and utilize Mockito 2.x. It has demos to show migrating Android app Mockito 1.x tests to Mockito 2.x.
This presentation walks the reader through implementing a simple web application and its tests using Python, Flask, and the Pytest testing framework. Emphasis is placed on following the process of test-driven development (TDD) in creating the application.
Cpp Testing Techniques Tips and Tricks - Cpp EuropeClare Macrae
This document provides tips and techniques for testing C++ code, including:
- Use a test framework and get to know it well
- Prioritize testable code over perfect code
- Be creative in testing legacy code, such as using golden master tests or approval tests
- Maintain tests by filtering slow tests from continuous integration and fixing flickering tests
You’re finally doing TDD, but your past mistakes are catching up with you. No matter what you do, you can’t get rid of the gaping black holes caused by your legacy code.
In this presentation, we learn about the causes of legacy code and the reasons it is so difficult to work with. Then we discuss various techniques to test untestable code, revive and simplify incomprehensible code, redesign stable yet untested code, and repair that rift we created in the time-space continuum.
The document discusses strategies for working with legacy code, which is code inherited from previous developers or older versions that often lacks tests and good documentation. It defines legacy code and outlines challenges like poor structure, dependencies, and lack of tests. It then provides approaches for modifying legacy code like identifying what to change and test, breaking dependencies, writing tests, and refactoring code in small, tested increments. Specific tactics are presented like using seams, sprouting methods, and interfaces to break dependencies and allow testing legacy code. The importance of understanding the system and increasing test coverage before making changes is emphasized.
Stopping the Rot - Putting Legacy C++ Under TestSeb Rose
The document discusses introducing unit testing to legacy C++ code. It covers choosing a testing framework, writing initial tests and mocks, and various refactoring techniques like wrapping dependencies, extracting components, and adding non-intrusive C seams to facilitate testing. The goal is to incrementally make the code more testable while maintaining functionality through practices like test-driven development.
- Testing shows the presence, not the absence of bugs. Tests are driven by requirements and business rules, focusing only on relevant cases rather than testing everything.
- Tests improve quality and confidence by verifying that each scenario works as expected. Tests serve as live documentation of the system.
- While testing has been used for decades in different forms like debugging, demonstration, and evaluation, modern test-driven development and integrated testing frameworks from the 1990s helped establish testing as a mainstream practice.
The document discusses automated testing in Python and other languages. It covers unit testing, how unit tests work in Python using the unittest module, the benefits of testing like refactoring with confidence and faster debugging. It also briefly mentions test frameworks for other languages like Java, Perl, PHP and Erlang. The key themes are that testing finds bugs, helps refactor code safely, and that when frameworks have shortcomings the better approach is to help fix them rather than starting new ones.
The document discusses the Test Anything Protocol (TAP), which is a simple text-based interface for reporting test results. TAP can be used for regression testing code, systems monitoring, and performance testing. It originated for testing Perl code but has since been adopted by many other languages. TAP outputs test results in a structured format with directives to indicate test status, plans, and other metadata. Producers generate TAP output and consumers process and analyze the results. Popular Perl modules for producing and consuming TAP are discussed, as are implementations in other languages. Future enhancements to TAP like nested output and structured metadata are also outlined.
TDD and Simple Design Workshop - Session 1 - November 2018Paulo Clavijo
The document contains snippets of code and discussions around test-driven development (TDD) best practices. It discusses principles of TDD like writing tests first, keeping tests independent and self-contained, and refactoring code. It also provides examples of refactoring Java and Kotlin test code, including using custom assertions and organizing tests in arrange-act-assert blocks. Pair programming and software design principles like YAGNI, DRY and SOLID are also briefly mentioned.
MUTANTS KILLER - PIT: state of the art of mutation testing system Tarin Gamberini
The document discusses mutation testing and the PIT mutation testing system. It begins with an overview of mutation testing, which involves making small changes to a program to generate mutant versions and running tests against these mutants to evaluate test effectiveness. The document then covers key concepts of PIT including the various mutators it uses to generate mutants and how it leverages test coverage to efficiently run tests against mutants. An example using a sample Ticket class demonstrates how PIT reports can identify weaknesses in tests by showing mutants that were killed or lived. The document promotes using mutation testing and PIT to evaluate test quality and improve test effectiveness at finding faults.
The document discusses Google Test, an open source unit testing framework for C++ that can also be used for testing C code, providing an overview of its features and how to implement unit tests using common patterns like test fixtures, assertions, and death tests to validate expected failures. It also covers best practices for writing effective unit tests, including keeping tests independent, focused, and fast-running.
Mutation testing is a technique that involves modifying code to generate "mutants" in order to test test quality. MuTalk is a mutation testing tool for Smalltalk that generates mutants by applying mutation "operators" that make small changes to code, such as changing logical operators. Tests are then run to determine if they can detect and "kill" the mutants. Surviving mutants indicate untested code cases. MuTalk optimizes the process by only mutating and testing covered code. Mutation testing is effective because complex faults are often coupled to simple faults detected by killing mutants.
Test driven development and unit testing with examples in C++Hong Le Van
Test-driven development (TDD) relies on short development cycles of writing a failing test case, producing code to pass that test, and refactoring the code. Unit testing tests individual units of code by isolating each part and showing they work correctly. Boost.Test is a popular C++ unit testing framework that allows organizing tests into suites and fixtures, and provides assertions and output of results. A minimal Boost.Test example defines a test case using BOOST_AUTO_TEST_CASE that contains an assertion like BOOST_CHECK_EQUAL to test that 2+2 equals 4.
The document discusses how tests can become messy if certain principles are not followed. It begins with a story of a junior developer writing their first test code, which quickly becomes complicated by dependencies on global states and logging. This leads to brittle, non-isolated tests. The document emphasizes that testable code is not always good code, and production code should not be modified to enable tests. It promotes writing code that is loosely coupled and follows principles like dependency injection to be properly testable. Tests themselves can become messy if they violate DRY and KISS principles through duplication and overcomplication.
This document provides an introduction to creating graphical user interfaces (GUIs) with Perl/Tk. Perl/Tk allows the powerful programming capabilities of Perl to be combined with the Tk widget toolkit to easily configure GUI applications. It summarizes the requirements for using Perl/Tk, which are Perl and the Tk module, and gives an overview of common widgets like buttons, labels, and menus that can be used to build basic interfaces. The document then discusses geometry management, common options for widgets, and Tk commands like bindings to create interactive applications.
This document is a 241-page tutorial on the Perl 5 programming language. It was written by Chan Bernard Ki Hong and published in 2003. The document covers topics such as what Perl is, getting started with Perl, manipulating data structures, operators, conditionals, loops, and subroutines. It includes over 20 chapters to help readers learn Perl programming.
TDD and Simple Design Workshop - Session 1 - March 2019Paulo Clavijo
The document discusses test-driven development (TDD) and simple design. It introduces TDD and some of its core practices, including test-driven development, simple design, refactoring, and pair programming. It provides an agenda for a workshop that will cover these topics over three sessions, including extreme programming (XP), the four elements of simple design, test doubles, outside-in TDD, and SOLID principles. The workshop aims to communicate best practices for using technical practices to succeed with agile development.
Refactoring legacy code driven by tests - ENGLuca Minudel
re you working on code poorly designed or on legacy code that’s hard to test? And you cannot refactor it because there are no tests?
During this Coding Dojo you’ll be assigned a coding challenge in Java, C#, Ruby, JavaScript or Python. You will face the challenge of improving the design and refactoring existing code in order to make it testable and to write unit tests.
We will discuss SOLID principles, the relation between design and TDD, and how this applies to your solution.
Reading list:
Growing Object-Oriented Software, Guided by Tests; Steve Freeman, Nat Pryce
Test Driven Development: By Example; Kent Beck
Working Effectively with Legacy; Michael Feathers
Agile Software Development, Principles, Patterns, and Practices; Robert C. Martin (C++, Java)
Agile Principles, Patterns, and Practices in C#; Robert C. Martin (C#)
Mockito 2.x Migration - Droidcon UK 2018Hazem Saleh
Mockito 2.x solves many problems that most of the Android developers were having in their tests in Mockito 1.x. But what if you are having today large tests written in Mockito 1.x and PowerMock, will it be an easy task to migrate?
Unfortunately, it is not a straightforward task since Mockito 2 is not fully compatible with the old behaviour of Mockito 1.x. Adding to this complexity, If you are having PowerMock in your old tests, then you will have to face another dimension of complexity since most of PowerMock’s versions are having integration issues with Mockito 2.x.
This session goes through the tips and tricks that you need to consider in order to migrate to and utilize Mockito 2.x. It has demos to show migrating Android app Mockito 1.x tests to Mockito 2.x.
This presentation walks the reader through implementing a simple web application and its tests using Python, Flask, and the Pytest testing framework. Emphasis is placed on following the process of test-driven development (TDD) in creating the application.
Cpp Testing Techniques Tips and Tricks - Cpp EuropeClare Macrae
This document provides tips and techniques for testing C++ code, including:
- Use a test framework and get to know it well
- Prioritize testable code over perfect code
- Be creative in testing legacy code, such as using golden master tests or approval tests
- Maintain tests by filtering slow tests from continuous integration and fixing flickering tests
You’re finally doing TDD, but your past mistakes are catching up with you. No matter what you do, you can’t get rid of the gaping black holes caused by your legacy code.
In this presentation, we learn about the causes of legacy code and the reasons it is so difficult to work with. Then we discuss various techniques to test untestable code, revive and simplify incomprehensible code, redesign stable yet untested code, and repair that rift we created in the time-space continuum.
The document discusses strategies for working with legacy code, which is code inherited from previous developers or older versions that often lacks tests and good documentation. It defines legacy code and outlines challenges like poor structure, dependencies, and lack of tests. It then provides approaches for modifying legacy code like identifying what to change and test, breaking dependencies, writing tests, and refactoring code in small, tested increments. Specific tactics are presented like using seams, sprouting methods, and interfaces to break dependencies and allow testing legacy code. The importance of understanding the system and increasing test coverage before making changes is emphasized.
Stopping the Rot - Putting Legacy C++ Under TestSeb Rose
The document discusses introducing unit testing to legacy C++ code. It covers choosing a testing framework, writing initial tests and mocks, and various refactoring techniques like wrapping dependencies, extracting components, and adding non-intrusive C seams to facilitate testing. The goal is to incrementally make the code more testable while maintaining functionality through practices like test-driven development.
- Testing shows the presence, not the absence of bugs. Tests are driven by requirements and business rules, focusing only on relevant cases rather than testing everything.
- Tests improve quality and confidence by verifying that each scenario works as expected. Tests serve as live documentation of the system.
- While testing has been used for decades in different forms like debugging, demonstration, and evaluation, modern test-driven development and integrated testing frameworks from the 1990s helped establish testing as a mainstream practice.
The document discusses automated testing in Python and other languages. It covers unit testing, how unit tests work in Python using the unittest module, the benefits of testing like refactoring with confidence and faster debugging. It also briefly mentions test frameworks for other languages like Java, Perl, PHP and Erlang. The key themes are that testing finds bugs, helps refactor code safely, and that when frameworks have shortcomings the better approach is to help fix them rather than starting new ones.
The document discusses the Test Anything Protocol (TAP), which is a simple text-based interface for reporting test results. TAP can be used for regression testing code, systems monitoring, and performance testing. It originated for testing Perl code but has since been adopted by many other languages. TAP outputs test results in a structured format with directives to indicate test status, plans, and other metadata. Producers generate TAP output and consumers process and analyze the results. Popular Perl modules for producing and consuming TAP are discussed, as are implementations in other languages. Future enhancements to TAP like nested output and structured metadata are also outlined.
TDD and Simple Design Workshop - Session 1 - November 2018Paulo Clavijo
The document contains snippets of code and discussions around test-driven development (TDD) best practices. It discusses principles of TDD like writing tests first, keeping tests independent and self-contained, and refactoring code. It also provides examples of refactoring Java and Kotlin test code, including using custom assertions and organizing tests in arrange-act-assert blocks. Pair programming and software design principles like YAGNI, DRY and SOLID are also briefly mentioned.
MUTANTS KILLER - PIT: state of the art of mutation testing system Tarin Gamberini
The document discusses mutation testing and the PIT mutation testing system. It begins with an overview of mutation testing, which involves making small changes to a program to generate mutant versions and running tests against these mutants to evaluate test effectiveness. The document then covers key concepts of PIT including the various mutators it uses to generate mutants and how it leverages test coverage to efficiently run tests against mutants. An example using a sample Ticket class demonstrates how PIT reports can identify weaknesses in tests by showing mutants that were killed or lived. The document promotes using mutation testing and PIT to evaluate test quality and improve test effectiveness at finding faults.
The document discusses Google Test, an open source unit testing framework for C++ that can also be used for testing C code, providing an overview of its features and how to implement unit tests using common patterns like test fixtures, assertions, and death tests to validate expected failures. It also covers best practices for writing effective unit tests, including keeping tests independent, focused, and fast-running.
Mutation testing is a technique that involves modifying code to generate "mutants" in order to test test quality. MuTalk is a mutation testing tool for Smalltalk that generates mutants by applying mutation "operators" that make small changes to code, such as changing logical operators. Tests are then run to determine if they can detect and "kill" the mutants. Surviving mutants indicate untested code cases. MuTalk optimizes the process by only mutating and testing covered code. Mutation testing is effective because complex faults are often coupled to simple faults detected by killing mutants.
Test driven development and unit testing with examples in C++Hong Le Van
Test-driven development (TDD) relies on short development cycles of writing a failing test case, producing code to pass that test, and refactoring the code. Unit testing tests individual units of code by isolating each part and showing they work correctly. Boost.Test is a popular C++ unit testing framework that allows organizing tests into suites and fixtures, and provides assertions and output of results. A minimal Boost.Test example defines a test case using BOOST_AUTO_TEST_CASE that contains an assertion like BOOST_CHECK_EQUAL to test that 2+2 equals 4.
The document discusses how tests can become messy if certain principles are not followed. It begins with a story of a junior developer writing their first test code, which quickly becomes complicated by dependencies on global states and logging. This leads to brittle, non-isolated tests. The document emphasizes that testable code is not always good code, and production code should not be modified to enable tests. It promotes writing code that is loosely coupled and follows principles like dependency injection to be properly testable. Tests themselves can become messy if they violate DRY and KISS principles through duplication and overcomplication.
This document provides an introduction to creating graphical user interfaces (GUIs) with Perl/Tk. Perl/Tk allows the powerful programming capabilities of Perl to be combined with the Tk widget toolkit to easily configure GUI applications. It summarizes the requirements for using Perl/Tk, which are Perl and the Tk module, and gives an overview of common widgets like buttons, labels, and menus that can be used to build basic interfaces. The document then discusses geometry management, common options for widgets, and Tk commands like bindings to create interactive applications.
This document is a 241-page tutorial on the Perl 5 programming language. It was written by Chan Bernard Ki Hong and published in 2003. The document covers topics such as what Perl is, getting started with Perl, manipulating data structures, operators, conditionals, loops, and subroutines. It includes over 20 chapters to help readers learn Perl programming.
This document provides an overview of the Perl programming language. It describes what Perl is used for, its main features, how to get and install documentation, how to run Perl programs and common commands, and where to get help or report bugs. The document acts as a starting point for learning more about Perl from its extensive documentation.
This month's newsletter discusses the September Main Meeting and Clubhouse Open House. The Main Meeting will cover computing topics ranging from basic command line utilities to advanced 3D graphical desktops. It will include presentations on the power of the Windows command prompt and a preview of future 3D desktop interfaces. The Clubhouse Open House on September 9th will include a BBQ, raffles for computer equipment prizes, and tours of the Clubhouse facilities and refurbishing projects. PCC will also be promoting the group at the Hayward Street Fair on September 21st.
FOSE 2011: DNSSEC and the Government, Lessons LearnedNeustar, Inc.
At FOSE 2011, the panel discussion on the deployment of domain name system security extensions (DNSSEC) within government included Neustar VP and Senior Technologist, Rodney Joffe, who sat side-by-side with some of the industry’s best and discussed how federal IT managers can leverage private sector best practices to meet OMB and FISMA mandated DNSSEC requirements. Entitled “DNS-3: Private Sector Deployment in .com, .net, .org and Beyond,” the panel discussed lessons learned and how federal agencies that have yet to deploy DNSSEC can do so successfully. Visit http://www.ultradns.com for more information.
This document discusses the author's hobbies and things they enjoy, which include watching TV, using MSN, listening to music, and playing sports. Their favorite sport is tennis and they shared a link to a video about Carla Suarez Navarro, a professional tennis player.
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.
The document provides an introduction to automated testing in Perl. It discusses the benefits of testing, including catching bugs, enabling refactoring, and providing confidence during development. It also covers basic concepts like using Test::Simple and Test::More to write tests, and comparing values with "is()" instead of "ok()" for more informative failure messages. An example is given of writing tests to validate the documentation of the Date::ICal module, which uncovered real bugs in the documentation.
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.
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.
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.
The document discusses the benefits of testing code through test-driven development and continuous integration. It explains that testing allows developers to have confidence that code will work as intended and catch any unintended behaviors. Test-driven development involves writing tests before code to validate outcomes, and continuous integration runs test suites frequently to ensure new code stays compatible. Conditionals require thorough testing of all possible code paths to ensure robust code. Shared development relies on testing to verify any new changes don't break existing features.
perl often doesn't get updated because people don't have a way to know if their current code works with the new one. The problem is that they lack unit tests. This talk describes how simple it is to generate unit tests with Perl and shell, use them to automate solving problems like missing modules, and test a complete code base.
The document discusses testing code and assuring quality by learning to use the Perl modules Test::More, Perl::Critic, and Devel::Cover. It provides an overview of different testing techniques in Perl including writing unit tests, ensuring code quality and test coverage, and using the prove command-line tool to run tests.
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.
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.
Developer Tests - Things to Know (Vilnius JUG)vilniusjug
The document discusses various topics related to writing tests for software. It covers test structure and organization, what to test, using matchers, writing custom matchers, ignoring tests, handling exceptions, testing with time, testing collections, random values in tests, number of assertions per test, and decoupling in end-to-end tests. The presentation aims to provide best practices and anti-patterns to consider when writing and organizing test code.
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 contains information about test-driven development (TDD), including:
1) An anecdote about 10 software engineers being asked who would get off a plane knowing their company's beta software controls the plane. 9 raised their hands while the 10th said the plane would not take off if their software was running it.
2) Explanations of TDD focusing on writing tests before code to prove functionality, allowing for refactoring while maintaining confidence via tests.
3) Discussions of frameworks for writing tests, how to write tests including using assertions and expected exceptions, setting up and tearing down tests, and using mock objects to isolate units for testing.
Mal ganz ehrlich: Testen im Frontend hat noch nie viel Spaß gemacht. In meinem Talk möchte ich mit Jest eine Testbibliothek vorstellen, die genau das ändern kann. Jest ist ohne viel Konfiguration direkt einsetzbar und bringt alles mit, was man von einer Testbibliothek erwartet (und noch mehr). An vielen praktischen Beispielen möchte ich meine Lieblingsfeatures wie z.B. Snapshot-Tests, Mocking oder das tolle CLI erläutern und zeigen, dass Testen im Frontend durchaus Spaß machen kann. Eine Ausrede weniger, um auf das Testen im Frontend zu verzichten! Die Zuhörer sollen einen Überblick über die Funktionsweise und die Einsatzbereiche von Jest bekommen. Sie lernen, wie sie mit Jest im Werkzeugkoffer für die Tests ihres Frontend-Projekts gut gerüstet sind.
Mal ganz ehrlich: Testen im Frontend hat noch nie viel Spaß gemacht. In meinem Talk möchte ich mit Jest eine Testbibliothek vorstellen, die genau das ändern kann. Jest lässt sich ohne viel Konfiguration direkt einsetzen und bringt alles mit, was man von einer Testbibliothek erwartet (und noch mehr).
An vielen praktischen Beispielen möchte ich meine Lieblingsfeatures wie Snapshot-Tests, Mocking oder das tolle CLI erläutern und zeigen, dass Testen im Frontend durchaus Spaß machen kann. Eine Ausrede weniger, um auf das Testen im Frontend zu verzichten!
Vorkenntnisse:
Grundlegende JavaScript-Kenntnisse.
Lernziele:
Die Teilnehmer sollen einen Überblick über die Funktionsweise und die Einsatzbereiche von Jest bekommen. Sie lernen, wie sie für Tests in Frontend-Projekten mit Jest im Werkzeugkoffer gut gerüstet sind.
The document discusses software testing and quality assurance. It explains that testing is an essential part of the software development process and should be planned from the early stages. There are different types of testing techniques, including black-box and white-box testing, that help identify bugs and errors in software. Quality assurance involves verifying and validating the software development process.
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.
Ivanti’s Patch Tuesday breakdown goes beyond patching your applications and brings you the intelligence and guidance needed to prioritize where to focus your attention first. Catch early analysis on our Ivanti blog, then join industry expert Chris Goettl for the Patch Tuesday Webinar Event. There we’ll do a deep dive into each of the bulletins and give guidance on the risks associated with the newly-identified vulnerabilities.
A Comprehensive Guide to DeFi Development Services in 2024Intelisync
DeFi represents a paradigm shift in the financial industry. Instead of relying on traditional, centralized institutions like banks, DeFi leverages blockchain technology to create a decentralized network of financial services. This means that financial transactions can occur directly between parties, without intermediaries, using smart contracts on platforms like Ethereum.
In 2024, we are witnessing an explosion of new DeFi projects and protocols, each pushing the boundaries of what’s possible in finance.
In summary, DeFi in 2024 is not just a trend; it’s a revolution that democratizes finance, enhances security and transparency, and fosters continuous innovation. As we proceed through this presentation, we'll explore the various components and services of DeFi in detail, shedding light on how they are transforming the financial landscape.
At Intelisync, we specialize in providing comprehensive DeFi development services tailored to meet the unique needs of our clients. From smart contract development to dApp creation and security audits, we ensure that your DeFi project is built with innovation, security, and scalability in mind. Trust Intelisync to guide you through the intricate landscape of decentralized finance and unlock the full potential of blockchain technology.
Ready to take your DeFi project to the next level? Partner with Intelisync for expert DeFi development services today!
Main news related to the CCS TSI 2023 (2023/1695)Jakub Marek
An English 🇬🇧 translation of a presentation to the speech I gave about the main changes brought by CCS TSI 2023 at the biggest Czech conference on Communications and signalling systems on Railways, which was held in Clarion Hotel Olomouc from 7th to 9th November 2023 (konferenceszt.cz). Attended by around 500 participants and 200 on-line followers.
The original Czech 🇨🇿 version of the presentation can be found here: https://www.slideshare.net/slideshow/hlavni-novinky-souvisejici-s-ccs-tsi-2023-2023-1695/269688092 .
The videorecording (in Czech) from the presentation is available here: https://youtu.be/WzjJWm4IyPk?si=SImb06tuXGb30BEH .
Salesforce Integration for Bonterra Impact Management (fka Social Solutions A...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on integration of Salesforce with Bonterra Impact Management.
Interested in deploying an integration with Salesforce for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Skybuffer SAM4U tool for SAP license adoptionTatiana Kojar
Manage and optimize your license adoption and consumption with SAM4U, an SAP free customer software asset management tool.
SAM4U, an SAP complimentary software asset management tool for customers, delivers a detailed and well-structured overview of license inventory and usage with a user-friendly interface. We offer a hosted, cost-effective, and performance-optimized SAM4U setup in the Skybuffer Cloud environment. You retain ownership of the system and data, while we manage the ABAP 7.58 infrastructure, ensuring fixed Total Cost of Ownership (TCO) and exceptional services through the SAP Fiori interface.
Digital Marketing Trends in 2024 | Guide for Staying AheadWask
https://www.wask.co/ebooks/digital-marketing-trends-in-2024
Feeling lost in the digital marketing whirlwind of 2024? Technology is changing, consumer habits are evolving, and staying ahead of the curve feels like a never-ending pursuit. This e-book is your compass. Dive into actionable insights to handle the complexities of modern marketing. From hyper-personalization to the power of user-generated content, learn how to build long-term relationships with your audience and unlock the secrets to success in the ever-shifting digital landscape.
This presentation provides valuable insights into effective cost-saving techniques on AWS. Learn how to optimize your AWS resources by rightsizing, increasing elasticity, picking the right storage class, and choosing the best pricing model. Additionally, discover essential governance mechanisms to ensure continuous cost efficiency. Whether you are new to AWS or an experienced user, this presentation provides clear and practical tips to help you reduce your cloud costs and get the most out of your budget.
Your One-Stop Shop for Python Success: Top 10 US Python Development Providersakankshawande
Simplify your search for a reliable Python development partner! This list presents the top 10 trusted US providers offering comprehensive Python development services, ensuring your project's success from conception to completion.
How to Interpret Trends in the Kalyan Rajdhani Mix Chart.pdfChart Kalyan
A Mix Chart displays historical data of numbers in a graphical or tabular form. The Kalyan Rajdhani Mix Chart specifically shows the results of a sequence of numbers over different periods.
Programming Foundation Models with DSPy - Meetup SlidesZilliz
Prompting language models is hard, while programming language models is easy. In this talk, I will discuss the state-of-the-art framework DSPy for programming foundation models with its powerful optimizers and runtime constraint system.
Nunit vs XUnit vs MSTest Differences Between These Unit Testing Frameworks.pdfflufftailshop
When it comes to unit testing in the .NET ecosystem, developers have a wide range of options available. Among the most popular choices are NUnit, XUnit, and MSTest. These unit testing frameworks provide essential tools and features to help ensure the quality and reliability of code. However, understanding the differences between these frameworks is crucial for selecting the most suitable one for your projects.
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAUpanagenda
Webinar Recording: https://www.panagenda.com/webinars/hcl-notes-und-domino-lizenzkostenreduzierung-in-der-welt-von-dlau/
DLAU und die Lizenzen nach dem CCB- und CCX-Modell sind für viele in der HCL-Community seit letztem Jahr ein heißes Thema. Als Notes- oder Domino-Kunde haben Sie vielleicht mit unerwartet hohen Benutzerzahlen und Lizenzgebühren zu kämpfen. Sie fragen sich vielleicht, wie diese neue Art der Lizenzierung funktioniert und welchen Nutzen sie Ihnen bringt. Vor allem wollen Sie sicherlich Ihr Budget einhalten und Kosten sparen, wo immer möglich. Das verstehen wir und wir möchten Ihnen dabei helfen!
Wir erklären Ihnen, wie Sie häufige Konfigurationsprobleme lösen können, die dazu führen können, dass mehr Benutzer gezählt werden als nötig, und wie Sie überflüssige oder ungenutzte Konten identifizieren und entfernen können, um Geld zu sparen. Es gibt auch einige Ansätze, die zu unnötigen Ausgaben führen können, z. B. wenn ein Personendokument anstelle eines Mail-Ins für geteilte Mailboxen verwendet wird. Wir zeigen Ihnen solche Fälle und deren Lösungen. Und natürlich erklären wir Ihnen das neue Lizenzmodell.
Nehmen Sie an diesem Webinar teil, bei dem HCL-Ambassador Marc Thomas und Gastredner Franz Walder Ihnen diese neue Welt näherbringen. Es vermittelt Ihnen die Tools und das Know-how, um den Überblick zu bewahren. Sie werden in der Lage sein, Ihre Kosten durch eine optimierte Domino-Konfiguration zu reduzieren und auch in Zukunft gering zu halten.
Diese Themen werden behandelt
- Reduzierung der Lizenzkosten durch Auffinden und Beheben von Fehlkonfigurationen und überflüssigen Konten
- Wie funktionieren CCB- und CCX-Lizenzen wirklich?
- Verstehen des DLAU-Tools und wie man es am besten nutzt
- Tipps für häufige Problembereiche, wie z. B. Team-Postfächer, Funktions-/Testbenutzer usw.
- Praxisbeispiele und Best Practices zum sofortigen Umsetzen
Introduction of Cybersecurity with OSS at Code Europe 2024Hiroshi SHIBATA
I develop the Ruby programming language, RubyGems, and Bundler, which are package managers for Ruby. Today, I will introduce how to enhance the security of your application using open-source software (OSS) examples from Ruby and RubyGems.
The first topic is CVE (Common Vulnerabilities and Exposures). I have published CVEs many times. But what exactly is a CVE? I'll provide a basic understanding of CVEs and explain how to detect and handle vulnerabilities in OSS.
Next, let's discuss package managers. Package managers play a critical role in the OSS ecosystem. I'll explain how to manage library dependencies in your application.
I'll share insights into how the Ruby and RubyGems core team works to keep our ecosystem safe. By the end of this talk, you'll have a better understanding of how to safeguard your code.
6. improve bug reports
q test output can pinpoint errors
q easily generated by end users
run this and send me the output
7. enable refactoring
q you break it, you know it right away
q side effects immediately evident
q well-tested code tends to be more modular
x I had several pre-existing modules with similar behavior to test.
They were only tangentially related. After the second test suite
turned out almost the same, I realized I needed a parent class. I
moved most of the tests to the parent class and the inherited
classes ended up much simpler and very much shorter. Their tests
were much simpler, too. This gave me less code to maintain, fewer
tests to write, and more flexibility for adding new features.
8. improve API
q hard to test code may be hard to use
q writing a test first forces you to use the interface before you
create it
x simpler interfaces are easier to test
x smaller functions are easier to reuse
9. promote automation
x easy to test code is usually well-decoupled
x easy to test code is, by definition, scriptable
10. ease maintainability
q tests are a safety net
x if you don't understand this by now, I'll repeat it once again
q well-written tests serve as a sort of documentation
x demonstrate what features the software should have
x demonstrate what behavior the code should express
12. Don't be Scared!
q writing good tests exercises the same muscles as writing good
code
q if you can write code, you can write tests
q if you can write good code, you can be taught to write good
tests
13. Testing Has Psychological Benefits
q writing tests (especially test first) makes it easier to write tests
q well-tested code is more fun to hack
q test-first programming gives instant feedback
q that's instant positive feedback, most of the time
14. Perl makes it easy
q ExtUtils::MakeMaker and the 'test' target
q Test::* modules hide the Test::Harness expectations
q if lazy dopes like us can do it, you can too!
16. Thinking "ok"
print "ok";
print "not ok";
q basis for all tests
q a simple boolean condition
q generally numbered sequentially
17. More thinking "ok"
q why printing is a loss:
x same arguments as using subroutines (duplicate code)
x manual test renumbering
x no diagnostics unless you provide them
Ë what matched
Ë what didn't match
Ë which test failed and where
x no built-in provision for more complex constructs
x can be hard to maintain
18. The ok() function
ok( 1 == 1 );
q basis for all Test::Simple, Test::More, Test::Builder tests
q a simple boolean condition
q why it's a win:
x alleviates duplicate code
x associates a name with a test
x expresses test intent more clearly
x avoids portability concerns
20. planning tests
q helps catch too many/not enough test errors
q helps identify which test fails
q required by Test::Harness
use Test::Simple tests => 10;
use Test::Simple 'no_plan';
21. tests => n
q produces 1..n output for Test::Harness
q should be set when the test suite is complete
22. no_plan
q produces 1..actual output at the end of the test
q when you don't know how many tests will run
q very handy while developing a module
q not so handy when distributing a module
23. ok()
q scalar context of operands
q first argument always true or false
q second argument optional, test name
q condition is code expression of the test name
q test name is a declaration of the intent of the condition
25. ok() failing
ok( 0, '0 should be true' );
not ok 2 - 0 should be true
# Failed test (demotest.pl at line 17)
26. success is not a gray area (individual tests)
q pass, or fail, there is no maybe
q test the smallest piece possible
q test one thing at a time
q pass quietly
x avoid errors
x avoid warnings
x test for errors and warnings if you must
27. success is all or nothing (test suite)
q stamp out expected failures
x undermine confidence in the code
x clutter up screens and logs
x hide new problems
q keeping changes small helps localize damage
q keeping tests working helps localize damage
q there are ways to isolate platform-specific tests
29. catching regressions
q most bugs aren't new, they happen again and again
q why let them reoccur?
q write a test for every new bug
30. testing first
q teeny, tiny, mini-iterations
q break each task into boolean expressions
q "What feature do I need next?"
x smallest element of overall task
x one small step at a time
31. The two test-first questions
q "How can I prove that this feature works?"
x 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
32. writing testable code
q the smaller the unit, the better
q the simpler the unit, the better
q the better the test suite, the easier it is to refactor
q writing your tests first promotes this!
33. distributing tests
q Test.pm is easier to distribute
x single module, does not depend on Test::Builder
x compatible with Test::More API
q Test::Simple suite can be bundled with module
x CGI.pm does this, among others
q Test::Simple ships with 5.8
q a module can depend on Test::Simple
35. graduating from Test::Simple to Test::More, or why
ok() is not enough
q one bit of data -- either it passed or it failed
q contains little debugging information
x what did you get?
x what did you receive?
x do you really want to exchange "add a print at line 43" emails?
q true laziness is a sign of good testing
36. matching things - is()
q asks the question "are these two things equal?"
q does a pretty good job of guessing at the type of equality
q takes an optional test name, so use one
q special cased for 'undef'
37. is() passing
is( 2 + 2, 4, 'Two plus two should be four' );
ok 1 - Two plus two should be four
38. is() failing
is( 2 + 2, 5, 'Two plus two should be five' );
not ok 2 - Two plus two should be five
# Failed test (demotest.pl at line 8)
# got: '4'
# expected: '5'
39. matching things - isnt()
q asks the question "are these two things not equal?"
q essentially the opposite of is()
40. isnt() passing
isnt( 2 + 2, 5, 'Two plus two should not be five' );
ok 3 - Two plus two should not be five
41. isnt() failing
isnt( 2 + 2, 4, 'Two plus two should not be four' );
not ok 4 - Two plus two should not be four
# Failed test (demotest.pl at line 10)
# '4'
# ne
# '4'
1..4
42. matching things - like()
q applies a regular expression to a string
q first argument is the string
q second argument is a regular expression
x compiled with qr//, where Perl version supports that
x a string that looks like a regex '/foo/', otherwise
43. like() passing
like( 'foobar', qr/fo+/,
'+ quantifier should match one or more' );
ok 5 - + quantifier should match one or more
44. like() failing
like( 'fbar', qr/fo+/,
'+ quantifier should match zero or more' );
not ok 6 - + quantifier should match zero or more
# Failed test (demotest.pl at line 12)
# 'fbar'
# doesn't match '(?-xism:fo+)'
45. matching things - unlike()
q essentially the opposite of like()
q the same rules apply
47. unlike() failing
unlike( 'foobar', qr/bar/, 'foobar should not match bar' );
not ok 8 - foobar should not match bar
# Failed test (demotest.pl at line 14)
# 'foobar'
# matches '(?-xism:bar)'
1..8
48. exploring behavior - use_ok()
q (these tests all provide their own test names)
q see if a module compiles and can be import()ed
q load a module and import() it
q activates at runtime, not compile time!
q provides a default test name so you don't have to
q allows optional imports to be passed
50. use_ok() failing
use_ok( 'No::Module' );
not ok 12 - use No::Module;
# Failed test (demotest.pl at line 20)
# Tried to use 'No::Module'.
# Error: Can't locate No/Module.pm in @INC (@INC
# contains: /usr/lib/perl5/5.6.1/i386-linux
# /usr/lib/perl5/5.6.1
# /usr/lib/perl5/site_perl/5.6.1/i386-linux
# /usr/lib/perl5/site_perl/5.6.1
# /usr/lib/perl5/site_perl .) at (eval 6) line 2.
51. exploring behavior - require_ok()
q see if a module compiles
q load a module, but do not import() it
q also provides a default test name
53. require_ok() failing
require_ok( 'No::Module' );
not ok 14 - require No::Module;
# Failed test (demotest.pl at line 23)
# Tried to require 'No::Module'.
# Error: Can't locate No/Module.pm in @INC (@INC
# contains: /usr/lib/perl5/5.6.1/i386-linux
# /usr/lib/perl5/5.6.1
# /usr/lib/perl5/site_perl/5.6.1/i386-linux
# /usr/lib/perl5/site_perl/5.6.1
# /usr/lib/perl5/site_perl .) at (eval 8) line 2.
54. exploring behavior - isa_ok()
q see if an object is a type of reference
q can be an object
x but not a class
x it exists to save you from having to make three extra constructor
tests
Ë did it return something defined?
Ë is that something a reference?
Ë is that reference an object?
q respects inheritance
q can be a reference type (scalar, array, hash, io, code)
56. isa_ok() failing
isa_ok( {}, 'IO::Socket' );
not ok 16 - The object isa IO::Socket
# Failed test (demotest.pl at line 26)
# The object isn't a 'IO::Socket' it's a 'HASH'
57. exploring behavior - can_ok()
q see if an object has named behavior(s)
q can be an object or a class
q pass several function or method names to test them all in a
single test
q loop over a can_ok() call to test them all in multiple tests
q respects inheritance, but falls afoul of AUTOLOAD() just like
UNIVERSAL::can() does
59. can_ok() failing
can_ok( 'Test::More', 'autotest' );
not ok 18 - Test::More->can('autotest')
# Failed test (demotest.pl at line 29)
# Test::More->can('autotest') failed
60. controlling things - skip()
q skips a specified number of tests
q generally used for things that will NEVER pass
q takes the reason to skip the tests and the number to skip
q should be in a labelled SKIP block
q should have a skip condition
61. skip() in action
SKIP: {
skip( 'Never on a Sunday', 2 ) if (localtime)[6] == 0;
can_ok( 'Perl::Porter', 'buy_beer' );
can_ok( 'Perl::Porter', 'wear_short_pants' );
}
ok 21 # skip Never on a Sunday
ok 22 # skip Never on a Sunday
62. controlling things - todo()
q marks a specified number of tests as known failures
q generally used for failures
x use sparingly!
x use for features that aren't quite finished
x use for bugs that aren't quite fixed
x don't let these add up: they undermine the suite
q should be in a labelled TODO block
q must localize the $TODO variable with the name
63. todo() in action
TODO: {
local $TODO = 'The alien overlords have not arrived';
is( $smallpox->status(), 'ready', 'Smallpox ready' );
ok( @cow_decoys > 1000, 'Bait ready...' );
}
not ok 23 - Smallpox ready # TODO The alien overlords have
not arrived
# Failed (TODO) test (demotest.pl at line 46)
# got: 'replenishing'
# expected: 'ready'
not ok 24 - Bait ready... # TODO The alien overlords have
not arrived
# Failed (TODO) test (demotest.pl at line 47)
64. controlling things - diag()
q display a (list of) diagnostic message(s)
q guaranteed not to interfere with the test harness
q gives no test number, pass, or fail
q useful for giving suggestions on tricky tests
65. diag() in action
diag( "Now that you know a bit about test writing,n",
"you have no excuse not to test." );
# Now that you know a bit about test writing,
# you have no excuse not to test.
66. controlling things - pass()
q make a test pass, unconditionally
q takes a test name -- that's it!
67. pass() in action
pass( 'Executive fiat should work' );
ok 19 - Executive fiat should work
68. controlling things - fail()
q makes a test fail, unconditionally
q also takes a test name, and that's it
69. fail() in action
fail( '... but we live in a meritocracy' );
not ok 20 - ... but we live in a meritocracy
# Failed test (demotest.pl at line 32)