Dear frantic and desperate programmers: if you are looking for an example of a populated android activity test file, go here.
Dear everyone else: you may wonder why that was necessary. Let me explain. There are five billion tutorials on how to build android apps and two on how to test them. Both are full lessons requiring a lot of knowledge of android to make sense of them and are based on Eclipse (deprecated) and not Android Studio, neither provides a decent sample file for steal-and-mutate learning. For those of us who want to write tests because we are learning to program for android and are worried a new technique might break our lovingly created app in ways we don’t know enough to fix, this is frustrating.
[For the slightly more advanced among you: yes, you could try searching github for the name of the class you know must be involved in your testing. Unfortunately the push for testing means that 95% of what you find are stubs with no actual tests.]
To be fair, I’m pretty weird in wanting to write tests so early. I complained to a stranger at a party that work on Hunger Tracker had stopped because I couldn’t find an android testing tutorial and he expressed surprised, because he’d watched people release much more complicated apps without a single automated test. I know that works for some people, but it would drive me absolutely nuts.
The point of testing isn’t to make the product work. The product is going to work, or you’ve failed. The point of testing is to make your work on the project faster and less stressful. Every time you change anything, and sometimes even when you’re sure you’ve changed nothing, you risk breaking something. The more time or changes that pass between you breaking something and you noticing it is broken, the more effort it takes to fix. You could manually test every time you change every little thing, but it’s boring, time consuming and prone to error. Computer science selects for the opposite of people who are good at doing the same thing over and over again.
So you do the programmer thing and write a program to do it for you. It’s just that the program is tests of the software. You can run this new program as often as paranoia or check in rules compel you. This frees up your time from manual testing, your mind from tracking your changes and worrying what might possibly have broken, and decreases the time to notice breaks. The mere act of writing the tests often encourages good code structure by making you think about it rigorously, the same way writing a program makes you define your problem until you practically don’t need a computer to do it. And in my particular case, when the project is as much about learning as it is producing anything, it’s good practice.
Good testing is especially critical in my case, because I’m working on this project in little bits at a time. If I break something and don’t notice it until two CLs later, I might as well be debugging someone else’s code. I know what people about the devs whose code they are forced to debug without tests or documentation, because I’ve said it, loudly, and at length. I may have expressed a wish for weapons. I would hate for someone to think that about me, especially myself, and testing is the cheapest way out of it.
Aceso Under Glass 