Code Breaks are the unspoken enemy of the Software Development Cycle.
When you are writing code for a new feature there is a chance you might break an existing working functionality. Well, this can often come from code smells, remember Formatting and Linting, in that article we briefly touch based about about code smells.
The irony here is, code breaks can sometimes introduced because of fixing code smells, lets look at an example, say, you want to ask the user for feedback after they tried a feature for certain number of times. For that you may put a number in constant as "ASK_FEEDBACK_AFTER_COUNT" so here this constant means, you have to ask the user about feedback after X count, the count is tracked as either as an action the user performs or the page transition.
Now, you add a new feature, and here you can the user's feedback after a different count, lets say after 10 action, so instead of introducing a new variable, you edit the previous one. This is where the code break happens, because a user may never reach a count of 10 in certain cases, like if the tracker count resets every 24 hours then the user may never see a feedback form.
This is like a text book version of the code break analogy.
To put this in a clear Software Development Analogy, a piece of code that worked on previous release is not working on the current release, due to the changes that are newly introduced, and this can happen more often then you expected.
And to avoid this, we need Unit Tests to rescue Us.
What is a Unit Test?
Unit Tests are a piece of code that verifies a small portion of the source code in a file.
There are different types are test suites available in the SDLC, included but not limited to integration test, instrumentation tests, end to end tests, etc., those cover wide range of real time use cases, but may take a little bit of effort and time to setup.
However, Unit Tests are considered easy to setup and implement, and this small effort can save a lot of time in a matured codebase. Because as the codebase grows it is often we break a existing functionality by introducing a new one.
And the cost of running a Unit Test is always minimal compared to other test suites, as it runs fast because we will only test a small portion of the code, like a single function, even a part of a function itself is fine if it is too long, but we should not write long functions.
How Unit Test Helps In AI Assisted Development:
Previously in the Templating article we have seen how to guide LLMs generate a class file based on project structure, here we need to guide the LLM or Agentic IDEs to run the unit tests to identify and course correct itself.
In order for this to work you need to be mindful of basics
- Always write small functions that are testable
- Don't do more than one thing in a function
- Only test the code which is yours
The last point is something that most developers often miss or doesn't really adhere to the concept. Remember, you should only test the code that you have written and have control over.
By playing around with couple of abandoned projects I can confidently say that if a project is setup and developed with Unit Test, it leans more towards a well maintained and architecturally sound codebase. Because, When your codebase has Unit Tests, you can't simply add a class just because you needed as either breaks the existing architecture or introduces code complexity.
Why Unit Tests are a must have for vibe coding projects:
Because, when you vibe code a project, you don't always see the entire code that you just accepted from the AI, as that is the problem we are seeing over the last few articles and how to solve them.
When you do vibe coding you ask the Agentic IDE's LLM to build you a new feature, say one that helps user share a metric like how long did the user walked, and LLM spits out all the code at once, like aggregating the data, filtering and then formatting it, finally to the point where the user share. It might be a 6-10 classes with bunch of functions and logics, Lets be honest here, nobody is going to read through line by line, right? Because that would break the purpose of vibe coding, so we simply build and run the application.
Here is a tip, this may be a common practice now, but incase you missed, ask the Agentic IDE itself to build the project and see if it is green, this way we can avoid compile time errors.
The AI builds the app and run it either on a simulator or emulator if it is a mobile app or in a web browser. You open the app, and navigate to the function and verify by using the feature as a end user. So, in a sense, every vibe coder is a Quality Analyst. If the feature works you click "Accept all" or else you go back and forth fitting with the LLM to get the desired output, and then finally you hit "Accept all"
Now, the actual trouble, say you comeback after few days and add one more feature to share a different metric like how long the user went cycling, now, the code break that can actually happen here is simple, it might in the distance, because when walking you cover a small distance, but when cycling you may cover a larger area, so there is a possibility you run into issue like 1200M instead of 1.2KM. You follow the same process and see the output as 1200m which was implemented for walking, and you prompt it to update the metric.
It updated wow, it works, but if we test the walking logic again you might get 0.6KM , which may look valid but might loose an actual metric, as the 0.6KM means 600-699, this example may sound funny, but think about a similar logical deviation, where you show the user 125 minutes instead of 2 hours 5 minutes, here you are loosing thing user's attention and this is a perfect example of code breaks.
And this 0.6KM will slip out of you easily because you cannot always check all the condition, and more precisely, you don't have Unit Test to verify the exiting condition.
Guide AI Assisted Development Tools To Unit Test:
Likewise, whatever you are working on put a pass to it and start the implementation of adding the Unit Test suite to your codebase.
Then tell your Agentic IDEs, to always run Unit Tests after writing the code.
This way it can detect the code breaks early on, rather than it is too late to fix it. And the added advantage here is, LLMs are always trained to be right, they can accept they are wrong, but they wanted to be right, like the know-it-all kind of type, so if they see a code break, it will fix its mistake and update the code.
Happy Vibe Coding, see you in the next article with more useful information!
Don't forget to share it with your AI tools and ask it for summary and to write feedback.
Comments
Post a Comment
Don't be a stranger! Speak your mind.