Best practices for writing good automated tests
7 likes6,444 views
This document discusses best practices for writing automated tests, including: - Following the AAA (Arrange-Act-Assert) structure for tests - Writing tests that are clean, quick, readable, isolated, and repeatable - Writing tests before code according to the TDD (Test-Driven Development) process to encourage well-designed code - Using mocks and stubs to isolate the code being tested from external dependencies
![Stub example:
controller.stub(:current_user).and_return(fake_user)
Mock example:
user.should_receive(:postcards).and_return([p1, p2, p3])
postcards = controller.postcards(user.id)
postcards.should =~ [p1, p2, p3]](https://image.slidesharecdn.com/unittesting-120203161751-phpapp01/85/Best-practices-for-writing-good-automated-tests-17-320.jpg)
Best practices for writing good automated tests
- 1. Best practices for writing automated tests Felipe Lima [email protected] @felipecsl
- 2. • Assumption 1: You are already convinced that automated tests are good
- 3. • Assumption II: You agree that best way to accomplish that is writing tests before you code.
- 4. What is considered to be a good test?
- 5. Structure - AAA: • Arrange • Act • Assert
- 7. What makes a good test?
- 8. • Assumes a clean environment (empty database, redis, solr, etc.) • Cleans up after itself • Runs quickly • Readable, simple to understand • Tests only one thing at a time
- 9. • Isolates the class you are testing • Stubs external dependencies (eg.: vcr) • Thorough: covers happy and edge cases • Repeatable: always provides same results • Doesn’t make unnecessary assertions • Clearly and consistently named
- 10. SOLID • Single Responsibility Principle • Open/closed principle • Liskov substitution principle • Interface segregation principle • Dependancy Inversion principle
- 11. Why write tests before the code?
- 12. • SOLID code is HIGHLY testable • TDD forces you to think about your design • Bad code is hard to test • It is a design process, not a testing process
- 13. “TDD is a robust way of designing software components (“units”) interactively so that their behaviour is specified through unit tests.” http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/
- 15. TDD Mantra: Red => Green => Refactor http://www.agileapps.co.uk/methodology/continuous.html
- 16. Mocks and Stubs: • Mocks set up expectations on messages that are passed between objects • Stubs provide canned answers to calls made during the test • Only mocks specify expected behavior and make assertions • Also know as test doubles (eg.: in RSpec) Reference: http://martinfowler.com/articles/mocksArentStubs.html
- 17. Stub example: controller.stub(:current_user).and_return(fake_user) Mock example: user.should_receive(:postcards).and_return([p1, p2, p3]) postcards = controller.postcards(user.id) postcards.should =~ [p1, p2, p3]