Discussion of testing patterns in the areas of unit testing, functional testing and system testing.

1. for Code, Components and Systems Patterns In Testing

2. overview Why write tests? Purist vs. Practitioner New Code vs. Legacy Code Unit Testing Functional Testing User Driven Testing Test Automation Ecosystem 5/20/2010 Presented by Joe Chavez

3. Why write tests? 5/20/2010 Presented by Joe Chavez Catch defects during implementation Software testing is not the same as hardware testing More moving parts Documentation is often stale or non-existent Tests provide opportunity to document the intent of a class, component or system with working code Once written, tests are repeatable with very little overhead Test help a team maintain and more importantly change code with reduced risk Software tests can drive hardware testing Automated tools cannot capture the intent of the code – especially dynamic intent These tools complement the coding of tests, not replace

4. PURIST vs. Practitioner 5/20/2010 Presented by Joe Chavez

5. PURIST vs. Practitioner Balance achieved with Pragmatism Context is key Type of code: new, legacy, generated, etc. Robustness of tools Complexity of design Developer skillset Management support Perception is often that writing test code is not contributing to the bottom line Reality a few tests now can save time during the integration/delivery phases of a project 5/20/2010 Presented by Joe Chavez

6. New Code vs. Legacy Code New Code Can benefit greatly from a Test Driven approach Identify critical areas in the requirements/design that deliver most value Typically can use the best of breed testing tools & frameworks Legacy Code Improve – White box with Test Driven approach Incorporate – Characterize actual behavior in isolation Rewrite – Analyze existing code and write tests as part of new code Pair programming is helpful Can work in code review mode while writing tests Ideal situation: original programmer is part of the pair 5/20/2010 Presented by Joe Chavez

7. New Code vs. Legacy Code Special Cases: Open Source Usually come with a test suite – use caution if there is no test suite Generated Code For C/C++ - characterize memory management Explore usage of generated code through writing tests 5/20/2010 Presented by Joe Chavez

8. Unit Testing Single Purpose Testing Focused on public methods of a class View through the caller eyes Typically one (1) assertion check for pass/fail Code scenarios to verify correct behavior under normal and abusive conditions Testing Frameworks C# - NUnit C++ - UnitTest++ Java – jUnit Mocking Frameworks 5/20/2010 Presented by Joe Chavez

9. Functional Testing Verify the integration of several components and/or classes Use same testing framework that unit tests use Good for integration testing new/legacy/open source/generated code Verification scenarios Data flow between components Actual vs. expected results at each stage Use case scenarios 5/20/2010 Presented by Joe Chavez

10. USER Driven Testing Data Driven System A system that can be configured for execution based on an input data set and will produced an expected set of output data Test Application May require development of a test application – typically a console application Accepts file based input and/or command line options Produces file based output 5/20/2010 Presented by Joe Chavez

11. Test Automation Run tests early and often Integrate into the development/build process Visual Studio post build event msbuild/ant/make scripts Continuous Integration support Silent success and error on failure If all tests succeed then report silently (X number of test passed) If any test fails then fail the build Report failed test with a context (i.e. failed assertion, stack trace) Take corrective action before moving on 5/20/2010 Presented by Joe Chavez

12. IN CONTEXT 5/20/2010 Presented by Joe Chavez