How TDD Teach us to Become a Firm Programmer

I started my journey of coding by delving into data science, specifically using Python, Pandas and Jupyter-Notebook as my first environment. In this setup, while wrangling the dataset and manipulate it, a mind paradigm that I has developed was the iteration running of code and see the output. If the output is not meet my expectation, then I will change it until it followed what I want. This common practice has molded me personally to become a person who always think later, run first which is not wrong in a certain situation, but could ruin you in backend development.

Until I learned about test code, during the time I have been allocated a task which required myself to create an API, was my first encountered of learning the test code and Test Driven Development (TDD).

At that time, my current mind paradigm was challenged by a different idea, by needing to be firm first, then execute. At first, it is such irritating whenever I saw all the errors, due to the code test failure.

However, after a month development and slowly used with it, my way of thiunking has gradually changed, since during the development process, I will put my objective first, before start building the code. It make me a an objective-focus person in order to met the requirement and the test code as the benchmark of the truthfulness.

Not only that, sometimes if I saw that my objective (or test) has sligthly wrong, I need to decide whether to alter the test methodology (reducing the test strictness) or by doing the last choice - moving the goalpost. The later choice is not good practice, but in some situation, it is necessary. Imagine that you want to test the strength of a car. You have decide the shoot the car with M16. Logically it is not the best approach, instead the best way is by crashing car to the wall (according the real world case scenario). Sometimes, the test is wrong, but most of the time your code does not met what you really want.

While, this might be not useful during modelling, due to the nature of experimenting and validating in order to approve or reject the null hypothesis, but at least the process of building pipeline (feature engineering, cleaning, imputation, etc.) would be robust and not a guessing game.