Testing Story 🧪
A tale of Productivity with Testing
Today I want to share my personal story into testing, and how it impacted my productivity as a Android developer!
I didn't delve into testing when I began my Android development journey.
I used to see two folders named androidTest and test that I didn’t use at all. Even as I went deeper into the field as an Android developer, I assumed that the testing that many books and speakers talked about (Testing and Automated Tests) were advanced topics; my focus remained on learning to create apps and finding clients (as I was a freelancer).
Eventually, I came to incorporate testing into a project for a client, as I believed it was important for a professional Software Developer to test apps for clients.
All software developers know we should test, and I wrote test code to verify my production code.
For example, I wrote code to verify if users were shown an error message with an unverified email when they tried to log into the app.
At the time, it seemed tedious since I knew it worked based on my manual tests.
I felt like it was a waste of time, so I abandoned it, completed the app, got my money, and started searching for my next client 😅.
After some time, I found a new client that needed an Android app. The app development process involved many changes throughout the development lifecycle.
I would develop and test everything manually:
The login.
Adding orders to the database.
Displaying error messages correctly when there is no internet.
And many other stuff.
My manual testing ensured everything was working correctly, but I didn’t like the workflow: every time the client sent me an update or a new feature request, I had to retest everything every time I made a code change!
I was also afraid of forgetting to test something with each iteration.
So I came up with this brilliant idea: I created a checklist in my notebook for that project to hold all the features I had to test so that I could give my client a good quality app.
Here are some of the items from that checklist:
Test if the login screen shows an error when we leave the email or password field empty.
Test if the login screen shows an error when we enter an invalid email.
Test if the login screen shows an error when entering a password smaller than 8 characters.
Test if the login screen shows an error when we enter a password containing just numbers or letters (it should be both).
Test if the app transitions from the login screen to the main screen when the user enters valid credentials in the database.
Test if the login screen shows an alert that there’s no internet connection detected when the user’s device is offline when they enter the required credentials.
The complete list is too extensive to replicate here, but you can understand how much manual testing I had to do, not just once, but with every change that had to be deployed to the client.
I called each testing cycle testing week: I would grab my phone and my notebook, start testing each checkpoint to see if the app was working correctly, mark it as a failure when it wasn’t, and then move to the next point.
Once I went through the checklist, I would check the code for every failed ❌ test separately and try to fix it, then test all over again. This process would take a week or so to complete. 🤔
This was when I remembered that androidTest folder. I remembered that I had written a test before and realized that if I write a test once, I could run it many times, without the frustration of manual testing.
So when I completed the app and began searching for my next client, I promised to incorporate automated tests into the next project.
Though that project took so much time and energy from me, it taught me that manual testing is hard to do efficiently and accurately at scale, and it eats into time I could spend on other productive tasks.
Now, I have a great green button in Android Studio that I can tap on to run all my tests, and guess how much time this takes? 6 seconds!
It really takes 6 seconds to check that the latest system build works correctly. If a test runs into a problem, I would correct it and run it alone in 20 ms before running the entire suite of tests again for another six lovely seconds = That’s 12 seconds and 20 ms compared to a week running a manual testing workflow.
I can confidently ship that code because I have the power of Automated Testing.
My software development worldview changed dramatically after applying software testing, especially with test-driven development.
Now I design and apply high-quality architecture, implement clean code, refactor, and create decoupled modules easily, and use all the best practices of Software Development thanks to Testing 🙏.
💡 Tip of the week
Simply, if you are not testing your code, try to write your first test this week.
PS. If you're struggling with an untestable code base, check out my course on Refactoring Legacy Code like a Pro.
You'll learn to start testing your legacy code base in the first two sections, which are completely FREE.
You can also enjoy a special 50% OFF using this Code: WEEKOFTEST50
Limited for the first 100 people to consume it.
📣 See you in the upcoming weeks with another Tip!
✍️ Charfaoui Younes.
✅ My preferred things this week
Here is a couple of digital content I’ve been consuming this week:
🎬 My YouTube Video 99% of Developers Don't Know this Compose Performance Trick!
🎬 YouTube Video Continuous Integration: That’s Not What They Meant.
👩💻 Github Repository Special Pizza Ordering App with Compose.
📑 Article How to Write Good Test by Mockito.
🕸️ Website: Mobile app CI workflow generator.
You would make my day if you share this newsletter with other developers 🙏.
🤗 Here are other ways I can help you with:
📞 Work with me 1:1 - book a coaching or strategy session for 60 minutes.
🔨 Course: Refactoring Legacy Code Like a Pro: A step-by-step approach for refactoring messy codebases into a Software Masterpiece.
🎥 Check out my YouTube channel: Discover tips on Android, Software Engineering, and productivity for developers.