How To Build an Effective Automated Test Suite

313 views

Published on

Utah Code Camp 2014

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
313
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

How To Build an Effective Automated Test Suite

  1. 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. 2. How to build an Effective Automated Test Suite David Adsit @davidadsit codeobsession.blogspot.com
  3. 3. Why test?
  4. 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. 5. 3 Great Virtues “We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.” - Larry Wall
  6. 6. The Full Test Suite
  7. 7. The Full Test Suite Unit Tests Integration Tests Acceptance Tests UI Tests
  8. 8. The Full Test Suite Unit Tests Integration Tests Acceptance Tests UI Tests
  9. 9. The Full Test Suite Unit Tests Integration Tests Acceptance Tests UI Tests
  10. 10. The Full Test Suite Unit Tests Integration Tests Acceptance Tests UI Tests
  11. 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. 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. 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. 14. The Double Loop
  15. 15. Layered Architecture Eric Evans, Domain Driven Design
  16. 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. 17. Questions & Demos
  18. 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. 19. Final Questions? David Adsit @davidadsit codeobsession.blogspot.com

×