My goal with this article is to talk a little about my history with automatized tests and my initial experience with it.
This post was originally published in my blog davidcosta.com.br.
I have working with programming since 2013, starting with PHP like home office for an E-commerce system integrated with ERP for a physical store. When I started programming I didn’t realize how many problems can show up that is developing a system is, for the most part, for human mistakes. As I was progressing in my career the projects grew in complexity, em the number of users and potential loss involved. The capacity to monitor issues was not humanly possible. Something was needed to be done to avoid many problems.
What makes me wake up to life was work in the SPA project with vanilha.js(Pure JavaScript)What was more complicated to be done with this project was to be able to change some without break an existing feature. Once this, happening it was a big loss of time. The process to launch any version depended on Apple’s review and approve the new updates. What it could late the launch in 1 to 5 days And when something has changed request from them, this could be slower.
This app was constituted by router system, forms, images upload and real-time data. Even using the best pattern of programming that I knew, it was always difficult to keep the feature’s consistency while was needed to do some new. I felt that with each new feature the system became more macaronic. To avoid future problems it was needed to make long check manuals. Testing every form, every link, every button manually to guarantee that everything was working.
In this period, Google launches a new tool called Puppeteer, which came with the object run the Google Chrome by the terminal, it’s could make simulations and tasks. I don’t lose time and start to use it, writing the commands that were needed to Puppeteer could test the functionalities. And what it took 30 minutes testing now just finish it in 5 minutes.
Since then, I have been looking to test with another side and start to learn and test everything that I could. For any good programming and experienced it to be, they are conducive to make mistakes. That means one single error can cause very big problems for the client and consequently for the developer. In addition to this, when it is testing. it’s adding documentation right and wrongs ways to use the system and to avoid that each change keeps working at the same time. Now I just can’t work in any project with tests again.
I hope that you enjoy this sorted history of my experience with tests. In the future, I pretend to talk more about this topic. If you have a different experience or similar please I would like to hear it. How is writing testing for you? And How much value do you see with this for the first time?
Top comments (3)
I once had to make a library to covert dates between Bikram Sambat calendar en.m.wikipedia.org/wiki/Vikram_Samvat and the Gregorian calendar. That thing additionally had to do various calculations like leave days.
Not much of code, but because the calendar systems are so different and there are so many edge cases it was really hard to test manually. But a good set of (unit) tests did rescue me.
I never had to touch that lib again after is got into production
I suppose that was not easy to work with timezone. Or Is it not apply? For my cases of tests with date time are always hard thing to do, especially with moment.js.
timezone hasn't been a problem, just pure date conversion between different calendar systems