We all know that not having automated tests is a sign of developers taking risky shortcuts. However, we tend to be a little shy as to why we so often feel compelled to take this shortcut — client budgets. Let’s just be honest, we know that we should have some significant amount of test coverage for our software and that over long-run, having well thought out automated tests will pay off over time in the form of fewer regressions and support incidents. The problem is that writing those tests tacks on roughly a twenty to twenty-five percent premium onto the initial development cost. In today’s competitive market, that’s a tough sell for the client and other stakeholders if they are not fully bought into the value of automated testing; the sad truth is most project bids go to the lowest bidder, explaining why roughly half of software projects fail according to IEEE. Starting from a position of no testing and no buy in, I’ve found a testing “foot in the door” strategy is effective at getting client buy-in, especially once I’ve educated them on the IEEE project failure statistics. The idea is not to pitch full test drive development with one hundred percent test coverage but rather just integration tests that can also serve as a poor man’s regression tests.
Integration Tests: Integration tests are in my opinion the most important types of test you could possibly have and if you’re only going to have one, have these. Simply put, they test where different software components meet and interact. For example, a common use is to test your REST API endpoints with various inputs to simulate what a real REST client would be sending. Here’s a simple sample test in Kotlin using the Spring framework:
@Test
fun testMissingUser() {
val expectedResult = "{ error: 'User Does Not Exist' }"
val headers = HttpHeaders()
headers.contentType = MediaType.APPLICATION_JSON
val entity = HttpEntity<Any>("{ \"email\" : \"nouser@nouser.com\", \"password\" : \"password\" }", headers)
val response = restTemplate.postForObject("/users/login", entity, String::class.java)
Assert.assertEquals(expectedResult, response)
}
This sample test that tries to login as a user that we know does not exist. It uses a simple assertion against an expected outcome to determine success. There are a number of ways this test could be improved such as making sure the user actually doesn’t exist before running the test, but for our purpose here this is fine. Basically, the idea of integration tests is to make sure that components communicate to each other in the expected way and to catch when they don’t.
Regression Tests: Regression tests are exactly what they sound like — tests designed to make sure that previously accepted functionality is still working as expected. In many cases integration tests can also be considered regression tests, but so can many other types of tests. In general you want your regression tests to cover the critical functionality of your project. This is where having integration tests in place if you can only pick one type of test makes sense, because the borders of your components will tend to be where you and (more importantly) your client will experience the majority of bugs. Some developers prefer to run regression tests only on the module or component they have most recently modified, but I recommend a different approach — simply running your entire test suite on every merge request or significant checkin. I admit this strategy can get pretty resource intensive as your test suit grows in size and complexity, but with the all amazing tools like Bitbucket Pipelines it’s pretty much trivial to follow my strategy even if you are on the most modest of development machines.
If you follow this strategy you won’t have anywhere near full test coverage or be truly practicing test drive development, but this should have an easier (read smaller) pill for your client to swallow and once you demonstrate value in the form of fewer major support incidents, your client will likely be interested in taking another step toward full test coverage. Questions? Comments? Mind-bending rage? Comment below or reach out on Twitter. Want to learn how a bot can help your business?
