Test Driven Development is the software engineering practice of building, testing the code, and refactoring/building again to make the test pass until the product is complete.
The Black Hole of Tests
Testing is kind of my thing. I appreciate how tests give me directions to the promised land of product launch. I think of tests as the highway signs on my coding journey. But there lies the black hole tests in that I need to figure out what to test and I am stuck testing everything. In a recent project, I found that I was writing server tests to see if the url was spelled correctly.
Questions to Consider Before You Write Tests
- What are the features that are needed in the first iteration of our product?
- What does the product owner envision for the user?
- What is the development timeline that the scrum master has laid out for the team?
As product owner, I worked with my team to determine what features would constitute a completed MVP. Our scrum master used waffle.io to plan out our sprints.
This is what our team brainstormed for the first week of our project. Our scrum master with all her expertise was able to point out what could be completed in a week and used this to organize our sprints. The items labeled with MVP became the tests I would write for our server since I was responsible for routing AJAX calls from the client to the database.
Using Supertest, I wrote three tests to ensure that the server
- can successfully respond to a GET request for a user profile
- can successfully respond to a POST request for a habit addition
- can successfully respond to a POST request to update a habit
At first I thought I written the tests incorrectly because the tests threw a SQL error, but in fact, this pointed to an error in our code that showed we had never instantiated the done() method. Lastly, I need to refactor my test so that the test object is deleted immediately after running the test.