This document discusses building an effective automated test suite. It recommends including unit tests, integration tests, acceptance tests, and UI tests. Unit tests are fast but don't verify interactions between units or desired system features. Integration tests ensure dependencies work as expected but test a narrow part of the system. Acceptance tests exercise the full system excluding the UI. UI tests verify user interaction but are slow and unreliable. Together, these different types of tests provide comprehensive coverage of a system.

1. Thanks to our Sponsors!
To connect to wireless
1. Choose Uguest in the wireless list
2. Open a browser. This will open a Uof U website
3. Choose Login

2. How to build an
Effective Automated
Test Suite
David Adsit
@davidadsit
codeobsession.blogspot.com

3. Why test?

4. Why test?
“Code without tests is bad code. It doesn't
matter how well written it is; it doesn't
matter how pretty or object-oriented or
well-encapsulated it is. With tests, we can
change the behavior of our code quickly
and verifiably.
Without them, we really don't know if our
code is getting better or worse.”
- Michael Feathers

5. 3 Great Virtues
“We will encourage you to develop the
three great virtues of a
programmer: laziness, impatience, and
hubris.”
- Larry Wall

6. The Full Test Suite

7. The Full Test Suite
Unit Tests
Integration Tests
Acceptance Tests
UI Tests

8. The Full Test Suite
Unit Tests
Integration Tests
Acceptance Tests
UI Tests

9. The Full Test Suite
Unit Tests
Integration Tests
Acceptance Tests
UI Tests

10. The Full Test Suite
Unit Tests
Integration Tests
Acceptance Tests
UI Tests

11. Unit Tests
Strengths
▪ Fast - which means you can have a lot of them
▪ Focused feedback when code breaks
▪ Provide executable documentation for each unit
Weaknesses
▪ Do not verify external dependencies
▪ Do not verify that units will work properly together
▪ Do not verify that the system supports desired features
▪ Do not answer questions about the “-ilities” of the system

12. Integration Tests
Strengths
▪ Verify that external dependencies behave as expected
▪ Provide early notification of API changes
▪ Facilitate changing external system providers
▪ Can tell us about the “-ilities” of external dependencies
▪ Help ensure clean boundaries with external dependencies
Weaknesses
▪ Usually significantly slower than unit tests
▪ Test only a very narrow part of the system
▪ Do not verify that the system supports desired features

13. Acceptance Tests
Strengths
▪ Help communicate features and requirements with business
▪ Verify the existence of features
▪ Help drive a clean API for the system
▪ Exercise the full system (excluding the UI)
Weaknesses
▪ Slower than unit tests
▪ Do not answer questions about the “-ilities” of the system

14. The Double Loop

15. Layered Architecture
Eric Evans, Domain Driven Design

16. User Interface Tests
Strengths
▪ Verify that the system can be assembled
▪ Verify that the user can interact with the system
▪ Can answer questions about the “-ilities” of the system
Weaknesses
▪ Slower than the pitch drop experiment
▪ Unreliable
▪ Require significant maintenance when changes occur
▪ Cannot provide confidence about system correctness

17. Questions
&
Demos

18. Links
Unit & Integration & Acceptance & UI:
https://github.com/davidadsit/LegacyCodeRescue
Unit & Acceptance:
https://github.com/davidadsit/bddtddfitnesse
Slides:
http://www.slideshare.net/davidadsit
Blog Post:
http://codeobsession.blogspot.com/2012/03/simpler-tests-what-kind-of-test-are-you.html

19. Final Questions?
David Adsit
@davidadsit
codeobsession.blogspot.com