program selection system

Summary

There are two questions worth asking oneself over and over when creating automated acceptance tests.

• What is the purpose of this test?
• Does the test express this purpose as clearly as possible?

This clinic uses exercises and examples to reinforce the good habit of writing tests with a clear purpose. Our focus is on favoring “declarative-style” tests over “procedural-style” tests. (See Bill Wake’s explanation of the difference at http://xp123.com/xplor/xp0503/index.shtml)

FitNesse out of the box does not seem to work for teams! In this demo I’ll show how to set up FitNesse so that development teams can do the following:

• Organize their Stories, Acceptance Criteria and Acceptance Test better
• Create different levels of test suites to give feedback at different levels
• Version control the FitNesse wiki with their source code
• Inline editing of their FitNesse pages, with out having to worry about Wiki syntax
• Integrate FitNesse with their builds, so that they can run their acceptance tests as part of their Continuous Integration loops

Test-driven development is now considered common sense in the OO world, but it is often not applied to database code. This session looks at the reasons why teams struggle with database test coverage and presents solutions and best practices for test-driven database development, from unit-testing stored procedures to Java/.NET integration tests that involve a database. We also present DbFit, an extension to FIT/FitNesse that makes database TDD easy, and discuss a case study of migrating database testing to this model at Edfinancial Services, a student loan servicing company.