#unit tests

This is the general problem about having AI write code for me. When I'm writing it myself and it doesn't work, I know that if I persevere, Google and experiment, I'll eventually get it working. With AI, there is no guarantee that no matter how much I reformulate the prompt, it will ever get it right. I don't know if I'm throwing my time away on a dead end.

Case in point: in my personal programming project I have code that deals with such concepts like Apache webserver logs, IP addresses and hostnames. When I ask Copilot to write unit tests for it, the tests it writes shows that it knows, for example, what Apache webserver log format is, what an IP address looks like, what a hostname looks like, and things like that. But it does not "look inside" my methods for which I'm writing tests, and it does not write tests for the logic of those methods. It writes tests more like "here's a check if an IP address is correctly formatted", when that's not what my code concerns itself with.

Recently i got into rust again. Partially for fun, partially to learn, partially because i always liked rust and ideas behind it, partially because it will soon be of use to me. I've been writing some code in it, learning to fight the borrow checker and the whole data-oriented mindset.

Today i was bored, so i decided to write some simple unit tests for my project, using the built-in features of cargo test and #[cfg(test)] etc.

Turns out i had a MAJOR bug in my program logic which caused my data structures to lose anywhere between 1 entry to 99% of stored data after an insertion operation. It somehow went unnoticed in all prior development, despite the fact that i used the library in some example executables.

The bug couldn't have been found by the compiler, since it was a program logic bug - no memory safety was harmed, all memory operations were perfectly safe. They just happened to drop references to a bunch of data nodes LMAO.

I was very unlikely to find the bug on my own, since - as i've said - i was sure the logic was working. All the programs i wrote seemed to return correct results.

What really struck me is that everyone talks about testing, and i have tried unit testing my projects in the past, be they in C, C++ or whatever, but i never got into the habit of doing it since it usually felt boring and never really provided me with much benefit - a minor bug there, an off by one here, a missing if statement somewhere else.

This, however, was the first time where a bug happened that i was very much unlikely to catch without unit tests, and said bug was actually a major one that would completely nullify usefulness of my project! I have never in the past experienced such direct and significant benefit from writing a few test cases.

It also felt funny in a way, since that's specifically what testing is for. Hell, i work in software testing (sort-of). Despite that, i usually let the message of TDD preachers fall on deaf ears. I guess i will not be doing that anymore lmao.

I felt very glad that i wrote the tests. In fact, fixing that bug also made me rethink the code i was using in that particular place, and realised it was VERY inefficient (i wrote it this way since borrow checker was being mean to me and i was just glad once the code seemed to work lmao). I learned a new standard library function that allowed me to write not only correct, but also more efficient code!

Afterwards i installed llvm-cov cargo addon to check my coverage, and noticed that some of the more complex branches of code were missing from it. This in turn made me write more test cases.

In the end i was so hyped up (by testing, of all things, lmao) that i added CI to my repo and can now enjoy a green checkmark next to my commits and log that says "all tests passing" :)

Scared to see the % test coverage for our codebase tbh

DAY 1283

I’m writing a lot more tests in my new job, and I generally like it a lot, but I’m still very bad at it. 

I find myself pretty frequently in situations where I’m thinking, “How in the world can I possibly test this thing?? It’s gonna be impossible to get at that [state/data/function/whatever]!”

So far every time that has happened, I talk to someone on my team and it ends up I have the wrong idea and definitely shouldn’t be trying to test that thing in that way, or even that I shouldn’t be testing it at all. 

Secrets of DRY: Say Goodbye to Repetition in Your Code

DRY is a mindset that can completely transform the way you create code, not merely a set of rules. When it comes to programming, efficiency is everything. Every developer wants to produce clear, simple code that is easy to read, maintain, and functions perfectly. The DRY (Don’t Repeat Yourself) concept applies in this situation. In-depth discussions of DRY’s concepts, advantages, and—above all—how to apply it to your projects will be covered in this extensive tutorial...

Learn more here: