I get it. Your application (mobile app or web app) doesn’t have tests and … well … you’re scared anytime you make changes.
Why? … well … because you’re not sure if you broke anything when you commit that code.
I encounter this a lot in the realm of software consulting.
There’s one simple way to remedy fear in your development lifecycle – tests.
The more tests you have, the more confident you will be that you didn’t screw anything up.
Yeah, Ok, I get it, but what if I don’t have any tests, where do I start?
Great question.
The first test you need to write is a Launch Test.
A launch test is a functional test that runs on your continuous functional server (or even your local machine if you don’t have CI yet) that confirms that the application you just compiled/etc will actually start and you can hit the home screen/home page of the app.
Simply check that your home screen text is showing as you would expect it to show and that certain key values are present. Simple. Done.
Hold up … but I know I didn’t break my home page. Why should I test it? Why is this important?
You said you didn’t have any tests. Are you sure you’re sure you didn’t break it?
Thought so, probably not.
The reason why this is important is that you may have made a change to the dependency injection code that uses reflection that does something at runtime that would only be exposed when the app is run.
What would happen if you didn’t catch that in development?
💥BOOM! CRASH! 💥
Exactly.
Furthermore what this first functional test does is give you a starting point. It gives you a jump off point. It’s your first test of many.
Yes, it might hit production servers. Ok, when you test manually you probably were hitting production servers too. Yikes. It is what it is.
The key thing to remember here is that you now have a test covering you to ensure your app launches.
What to Test Next
Ultimately the next thing you should be testing is your most used screens:
- Home/Main Screen
- Customers
- Orders
- Etc
Once you get some tests around these screens (do they load, do they work when interacted with) then you can refactor.
Refactor with Confidence
That’s the key takeaway here. Tests give you the confidence to do work that otherwise might be overly stressful and risky because you’re not sure what you’re breaking.
Functional (and integration) tests are the best place to start because they’re true end-to-end tests and they mimic what the end user is going to see and this is important because …
Nothing else matters more than the end user experience.
If the end user sees a screen that’s broken, gets a crash, or sees incorrect data they’re not going to be happy and they won’t give two cents that your app is powered by AI with advanced machine learning to render results from a globally decentralized blockchain network running on Ethereum.
User’s don’t care about your cool tech stack if your app doesn’t work.
To the user, if the app doesn’t work, it’s garbage.
… and …. well … at that point, let the 1-star reviews come flooding in.
So … if you don’t have any tests, start with some functional tests and then you can refactor with confidence and then and only then should you introduce more testing mythologies into your app.
PS: If your app is an Android app, quickly set up an Espresso launch test with the Espresso Test Recorder. Sam Edwards has a great course on it here.
“…Why should I test it? Why is this important?” definitely have fought this battle before with the same argument.
Having any test is often better than none, and having some tests definitely makes it easier to convince people to add more.