Makers Academy Day 9
Whilst working on the Oystercard challenge today in a group of three, a couple of times as the navigator I had asked our driver to ‘feature test’ a passing unit test in pry. My understanding of using pry as a ‘feature test’ wasn’t all that clear, sometimes I had used it to mock up an idea for new features and then write the unit time, and other times it would sense check a unit test I had already written.
Our driver described how he had been using a feature tests, and how switching back and forth between Irb and pry meant that there was no trace of these tests. Not only this but as we were experiencing, it was fairly arduous and repetitive work to keep switching from our text editor unit tests to our command line repl.
I’ve summarised below some key points made from my pair and our coach Sam Morgan about the benefits of using feature tests:
- Every User story should have a feature test
- Set up a feature test folder with the feature test spec file
- A feature tests is a composition of a Unit test
- Code is tested as both a feature and a unit test
We decided to create a feature test spec to run alongside our existing unit test spec:
This enabled us to check our feature test against our unit test in a systematic way. Our feature tests would test our user story and act as the scaffold upon which we’d then write our unit test. We could then experience the joy of watching both tests fail, and cross check error messages. This extra file served as a powerful guide in the creation of our code and streamlined our work flow into our text editor. For me having both sets of error messages helped direct the writing process, and gave me double information that created better tests and code.
It seems that there are a lot of different tests you can use for different purposes, here is a one line description of a few that I’ve encountered and how I understand them to work. Any feedback on these descriptions would be welcome!
Spike test: A quick test that you would run in your repl to spot check that your code is working as you’d expect it to.
Feature test: Is created for each user story and should mimic the program as though you had input from a user, to check that the output is correct. It’s a ‘traced’ version of a spike test.
Integration test: Both spike and feature tests form a part of the initial tests that you would run before creating a unit test, and in tandem with the unit tests once they have been written.
Unit test: Your main tests that check each aspect of your program is functioning as expected. Whenever there are dependencies (and it makes sense) it’s good practice to use doubles and method stubs to ensure consistency in these tests.
Looking forward to learning more about these tests and using them in the right contexts!