Some types of testing
There are several approaches for testing code and each come with their own set of challenges. Emily Bache, author of The Coding Dojo Handbook, writes about them in more detail on her blog - Coding is like cooking
- Test Last: in this approach, you code a solution and subsequently create the test cases.
- Problem 1: It’s difficult to create test cases after the code is completed.
- Problem 2: If test cases find an issue, it’s difficult to refactor the completed code.
- Test First: you design test cases and then write the code.
- Problem 1: You need a good design and formulating test cases increases the design stage, which takes too much time.
- Problem 2: Design issues are caught too late in the coding process, which makes refactoring the code more difficult due to specification changes in the design. This issue also leads to scope creep.
- Test-Driven: You write test cases parallel to new coding modules. In other words, you add a task for unit tests as your developers are assigned different coding tasks during the project development stage.
TDD focuses on writing code at the same time as you write the tests. You write small modules of code, and then write your tests shortly after. Patterns to apply to the code:
- Avoid direct calls over the network or to the database. Use interfaces or abstract classes instead.
- Implement a real class that implements the network or database call and a class which simulates the calls and returns quick values (
- Create a constructor that uses
Mocksas a parameter in its interface or abstract class.
Patterns to apply to unit tests:
- Use the
setupfunction to initialize the testing, which initializes common behavior for the rest of the unit test cases.
- Use the
TearDownfunction to release resources after a unit test case has finalized.
assert()to verify the correct behavior and results of the code during the unit test cases.
- Avoid dependency between unit test cases.
- Test small pieces of code.
Behavior-Driven Development (BDD) is a specialized version of TDD focused on behavioral specifications. Since TDD does not specify how the test cases should be done and what needs to be tested, BDD was created in response to these issues. Test cases are written based on user stories or scenarios. Stories are established during the design phase. Business analysts, managers and project/product managers gather the design specifications, and then users explain the logical functionality for each control. Specifications also include a design flow so test cases can validate proper flow. This is an example of the language used to create a BDD test story:
Story: Returns go to stock In order to keep track of stock As a store owner I want to add items back to stock when they’re returned
Scenario 1: Refunded items should be returned to stock Given a customer previously bought a black sweater from me And I currently have three black sweaters left in stock* When he returns the sweater for a refund* Then I should have four black sweaters in stock*
Scenario 2: Replaced items should be returned to stock* Given that a customer buys a blue garment* And I have two blue garments in stock* And three black garments in stock.* When he returns the garment for a replacement in black,* Then I should have three blue garments in stock* And two black garments in stock
Frameworks to Install
Suitesdefine the unit’s story.
Specsdefine the scenarios.
Expectationsdefine desired behaviors and results.
Jasmine has a set of helper libraries that lets you organize tests.