Writing Tests
No matter what principles, architecture or design pattern we decide to use, our goal should be: Make tests simpler. And everything will follow.
(Don’t try this at home, specially at work) Since I learn programming, up until my first year of my work, I didn’t write any single test. I passed my thesis, developed my first mini apps, deployed my first project on the company (to production!) and all of them are nice and working without a single test case.
Why don’t we write tests?
- Tests doesn’t act as a feature, instead, a hindrance for our next task.
- It’s hard keep doing test cases because we don’t see immediate accomplishment with it.
- It’s hard to add tests on your existing project because its too many.
Why should we write tests?
- You can easily refactor/optimize your code without testing each and every scenarios again. With this, you will have a consistent speed of development instead of getting slower and slower over time because you need to retest each and every scenarios that will be affected by your updates/changes.
- Your code will never encounter the same bug again, why? If you accidentally change a tested logic, your test will most likely fail and you will immediately notice before your code goes to production (this is scary 😱).
- Thinking what tests we should write often lead us finding bug in our code. Thus it helps our code much more stable.
- Your code will be much more stable, stable code means happy product owner/manager, and happy boss will lead to your promotion. 🎉 🎉
- Serves as your code documentation as well.
How should we write tests?
This is the tricky part, creating tests is not that simple and there are many pitfalls in it. When creating tests, try to think all of all the possible scenarios and edge cases that will make up your tests.
For example, clickable comment button only if you are logged in. What are the possible scenarios?
- should be able to click if logged in
- should not be able to click if not logged in
That’s it, most of the time its just two scenarios, success and fail.
Tips to overcome the cause why we don’t write tests:
When you encounter a bug, create a test for it first and let it fail then fix it on the code. By doing this, you already gain stability immediately and you’re also exercising TDD (Test Driven Development).
Why we tackle writing tests first instead of architectures, principles, coding patterns that will help us with it?
Because knowing the importance of it will make us write clean code naturally instead of writing clean code because we read something. If it’s the other way around, most of the time we make simple things complex because we are forcing to apply a pattern, architecture or principles that was not appropriate in our code. Remember KISS — Keep It Simple Stupid.
Exercises:
Here are some exercises for you to think what are the possible tests we can apply in these scenarios: (Answer below)
- Login with basic required validation
- Saving an item with unique name, overwrite if duplicate
- Tagging of item with these statuses: PENDING, VERIFIED, REJECTED
- Alphanumeric validation — string is valid if it contains either alphabet or numeric
Answers:
- Login with basic required validation
- should not proceed when username is empty
- should not proceed when password is empty
- should proceed if username and password is not empty
2. Saving an item with unique name
- should update item if name already exists
- should add item if name does not exist
3. Tagging of item with these statuses: PENDING, VERIFIED, REJECTED
- should tag item as pending|verified|rejected
- should not retag item if tag is same
4. Alphanumeric Validation
- should return true if contains both alphabet and numeric
- should return true if contains alphabet only
- should return true if contains numeric only
- should return false if contains special characters
If you found there’s something wrong or lacking on the exercises, feel free to point it out by commenting below.
Want to contribute? Comment down your scenarios that are tricky to think of tests.