Sometimes when you want to get a project off the ground quickly you tell yourself it’s okay to skip writing tests.
This often works well in the short term, as you meet a deadline. However, as time passes the manual testing tests gets too time consuming and you start to question your earlier decision. Skipping tests also comes from another place. You’re not sure how to test — maybe this is your first project and testing is an after thought. After all, you want to delivery the functionality above all else; I can cross that bridge when I come to it right?
Well, I’m here to argue that from which ever place you’re coming from, a small investment in the early stage will actually help you build the product faster and pay dividend later on.
Choose Your Tests Wisely (a brief intro to testing)
Let me start by drawing attention to the Mike Cohn’s test pyramid. It’s well known in the software community, and what’s also well known is the higher you go, the more coverage you get. Meaning you test more of the code. However, these high level tests are expensive and slow to write, not to mention they need high level knowledge of the system. Knowledge, a developer who works on a particular part of the system may not have.
In an ideal world yes you would have UI tests for every possible use case of the system and be done with it. However, in the real world we typically compromise for the sake of convenience, cost and time to write by choosing items lower down from the pyramid. Note, there are pyramids with more levels and with details of what exact categories they contain like regression testing, performance testing, integration testing and many more.
What’s interesting though, is that if we can take a top shelf item and create them for the same cost, and ease of use etc as ones from the bottom of the pyramid, we have the best of both.
You (probably) only need contract tests
Contract tests, if you can make them easy to write, provide a perfect choice for personal projects and quick builds. As you completely test the API implementation from the network layer as the test takes place outside of the system we’re writing. Let me take this a step further, and show a way to get these tests for free as part of the software design process.
As your building software, what are you doing? You’re creating UI/UX designs, making a system design etc, you’re also (hopefully) devising a data model. Well, this data model has intrinsic value, and we can use it test our API implementation.
Build Your Data Model With Apiary.io
Signup and start a new project. It’s free for the features I will talk about in this article. Then drop in the json usually I generate it from http://objgen.com/json.
There are a couple different languages you can choose and even variations in the language of how you can define things. I prefer the API Blueprint format and am experimenting with different formats.
Test With Dredd
- Install dredd (If you don’t have node or npm check here)
sudo npm install email@example.com --global
2. Make sure you have an apib file in your project directory and run
dredd api-description.apib http://127.0.0.1:3000
Writing APIs Can Now Be Done In Record Time
We’re now able to focus on building our backend, testing as we build. No postman or manual testing needed, it’s a great development experience. What blew my mind was, discovering Apiary.io provide a mock server based on the data model.
You can even use the mock server as a backend prototype
This enabled me to completely finish the frontend, whether an mobile app or web app, without doing any backend code. This sped up my development time greatly as I was able to make changes quickly, because changing a mock was far easier than a backend implementation. And then when the backend if finished, just flick the switch by changing the url in the frontend and you’re done.