I've been making apps for about 2 years, and in that time I never understood the community's obsession with unit testing. I figured that if I can run the app and see it working, what's the point in taking loads of time to write automated tests?
The answer revealed itself to me recently.
You don't write tests to make sure your code works now: you write tests so that you can spot your code breaking in the future.
Here's an example. We've written a file in RotaCloud for Android which contains a bunch of functions for working with time. Here's our method for formatting a timestamp - in seconds - as a 24-hour time:
fun Long.secondsToTime() {
return SimpleDateFormat("HH:mm", Locale.UK)
.format(this * 1000)
}
This function is pretty important to our app: if it breaks, suddenly everyone's rotas will be displaying incorrect information.
So what happens when a dev unwittingly changes this function like this?
fun Long.secondsToTime() {
return SimpleDateFormat("HH:mm", Locale.UK)
.format(this * 100)
}
This change will not cause a crash in the app, but it will mean that the whole system is pretty useless, and our users will not be happy.
So we wrote a test:
@Test
fun secondsToTimeTest() {
val timeInSeconds = 1523451825
val expectedTime = "13:03"
assertEquals(expectedTime, timeInSeconds.secondsToTime())
}
This is a really simple test, but running it before a new release ensures that this vital functionality keeps working.
We can extend these tests to cover some other requirements too e.g. the hour should always be two digits: 09:30 is correct, but 9:30 isn't.
So that was my testing epiphany. It's pretty easy to manually determine whether or not something works, just by looking at it. What automated tests do, however, is ensure that all the app's functionality continues to work in the future, without you having to manually look through the whole thing.
Testing is also incredibly useful for collaborative development: simply require everyone to run the test suite before submitting a pull request, and you'll find yourself having to deal with a lot fewer broken implementations.
Top comments (11)
That's a great epiphany!
I had a pretty similar one a few years ago, when I realised that writing tests first, is like drawing a blueprint for your application.
You can't build the wrong thing if the rules for what the thing should do are already written and, much like you point out in this article, you can't break the thing without seeing that it's wrong compared to the blueprint.
Then if you need to change the thing, you change the blueprints and alter the thing to fit them.
In general, it's always great to see folks discovering the value of testing 🙂
I won't lie when I say that I'm guilty of writing tests. It's never struck me as important and I've yet to see it be taught in a class but after reading this post and that comment, WOW.
That helps so much and explains the importance in a much better way! Awesome post!
You've touched on my number one bug-bear about programming classes in general (online, university or otherwise).
The attention testing receives is typically well below insufficient. Especially when, in a high functioning team and environment (and cross-functional environment for that matter) you're going to be spending upwards of 50% of your time writing tests for your code rather than the code itself.
This has slowly started to shift in the online realm, but in my experience universities and other "legitimate" institutions are lagging behind in this regard.
Test away, my friend. Test away!
Well, in TDD, tests are even more powerful than that: we use them to describe the application behavior, so when a newcomer arrives, he just have to look the tests and have a better idea of what the code is really supposed to do.
Great article!
I started working with unit testing a few months ago. As time goes by, I understand the importance of it more and more.
It even "saved me" once. I changed a certain part of my code, and it affected the code of a different developer.
Luckily we had unit tests covering both of our codes, so we identified the bug pretty quickly.
Yep, one of many reasons we write tests. The other big one for me is that it allows me to refactor and clean up with out fear that I broke something. When you use TDD it also allows you to spend less time in debug mode and more time actually doing what we like, writing code. I just feel more confident when I release my code.
Also often testing your code works is faster via unit tests than by using your UI to go to the right screen to perform the right actions. Especially when most of your code base has decent coverage with good mocks and similar it's often easier to confirm the bit of code you just wrote works via tests.
In this particular case, I wouldn't be worried that this code is going to break, but unit testing it allows it to be tested in isolation without having actually boot up your app, and get it into the state that it needs to be in to see the results. In addition, it affords future developers with an understanding of why this function is here, and how to use it, as well as giving you a place to test various edge cases.
That said, an integration test or e2e test would be useful to make sure that you've actually called the function correctly, in other words, that you've glued everything together properly.
I'm a rails developer and I don't do unit testing (I'm ashamed). Do you have any good tutorials to learn how to do it the right way?
Thanks!
Great video on youtube from Jim Weirich youtu.be/tg5RFeSfBM4
Awesome, thanks!