Patterns in Testing
0 likes667 views
The document discusses different types of software testing including unit testing, functional testing, and user driven testing. It explains why writing tests is important to catch defects, document code, and allow for safer changes. The document also discusses balancing purism with pragmatism in testing and different strategies for testing new code versus legacy code, including test-driven development and characterizing existing behaviors. It provides examples of testing frameworks for different languages and emphasizes integrating testing into the development and build process through continuous integration.
Patterns in Testing
- 1. for Code, Components and SystemsPatterns In Testing
- 2. overviewWhy write tests?Purist vs. PractitionerNew Code vs. Legacy CodeUnit TestingFunctional TestingUser Driven TestingTest AutomationEcosystem5/20/2010Presented by Joe Chavez
- 3. Why write tests?5/20/2010Presented by Joe ChavezCatch defects during implementationSoftware testing is not the same as hardware testingMore moving partsDocumentation is often stale or non-existentTests provide opportunity to document the intent of a class, component or system with working codeOnce written, tests are repeatable with very little overheadTest help a team maintain and more importantly change code with reduced riskSoftware tests can drive hardware testingAutomated tools cannot capture the intent of the code – especially dynamic intentThese tools complement the coding of tests, not replace
- 4. PURIST vs. Practitioner5/20/2010Presented by Joe Chavez
- 5. PURIST vs. PractitionerBalance achieved with PragmatismContext is keyType of code: new, legacy, generated, etc.Robustness of toolsComplexity of designDeveloper skillsetManagement supportPerception is often that writing test code is not contributing to the bottom lineReality a few tests now can save time during the integration/delivery phases of a project5/20/2010Presented by Joe Chavez
- 6. New Code vs. Legacy CodeNew CodeCan benefit greatly from a Test Driven approachIdentify critical areas in the requirements/design that deliver most valueTypically can use the best of breed testing tools & frameworksLegacy CodeImprove – White box with Test Driven approachIncorporate – Characterize actual behavior in isolationRewrite – Analyze existing code and write tests as part of new codePair programming is helpfulCan work in code review mode while writing testsIdeal situation: original programmer is part of the pair5/20/2010Presented by Joe Chavez
- 7. New Code vs. Legacy CodeSpecial Cases:Open SourceUsually come with a test suite – use caution if there is no test suiteGenerated Code For C/C++ - characterize memory managementExplore usage of generated code through writing tests5/20/2010Presented by Joe Chavez
- 8. Unit TestingSingle Purpose TestingFocused on public methods of a class View through the caller eyesTypically one (1) assertion check for pass/failCode scenarios to verify correct behavior under normal and abusive conditionsTesting FrameworksC# - NUnitC++ - UnitTest++Java – jUnitMocking Frameworks5/20/2010Presented by Joe Chavez
- 9. Functional TestingVerify the integration of several components and/or classesUse same testing framework that unit tests useGood for integration testing new/legacy/open source/generated codeVerification scenariosData flow between componentsActual vs. expected results at each stageUse case scenarios5/20/2010Presented by Joe Chavez
- 10. USER Driven TestingData Driven SystemA system that can be configured for execution based on an input data set and will produced an expected set of output dataTest ApplicationMay require development of a test application – typically a console applicationAccepts file based input and/or command line optionsProduces file based output5/20/2010Presented by Joe Chavez
- 11. Test AutomationRun tests early and oftenIntegrate into the development/build processVisual Studio post build eventmsbuild/ant/make scriptsContinuous Integration supportSilent success and error on failureIf all tests succeed then report silently (X number of test passed)If any test fails then fail the buildReport failed test with a context (i.e. failed assertion, stack trace)Take corrective action before moving on5/20/2010Presented by Joe Chavez
- 12. IN CONTEXT5/20/2010Presented by Joe Chavez