8
nanobot
173d

Killing people is bad. But, there should be a law to allow killing people who don't write proper unit tests for their code. And also those "team leaders" who approve and merge code without unit tests.

Little backstory. Starts with a question.

What is the most critical part of a quoting tool (tool for resellers to set discounts and margins and create quotations)? The calculations, right?
If one formula is incorrect in one use case, people lose real money. This is the component which the user should be able to trust 100%. Right?

Okay. So this team was supposed to create a calculation engine to support all these calculations. The development was done, and the system was given to the QA team. For the last two months, the QA team finds bugs and assigns those to the development team and the development team fix those and assigns it back to the QA team. But then the QA team realizes that something else has been broken, a different calculation.

Upon investigation, today, I found out that the developers did not write a single unit test for the entire engine. There are at least 2000 different test cases involving the formulas and the QA team was doing all of that manually.

Now, Our continuous integration tool mandates coverage of 75%. What the developer did was to write a dummy test case, so that the entire code was covered.

I really really really really really think that developers should write unit tests, and proper unit tests, for each of the code lines (or, “logical blocks of code”) they write.

Comments
  • 3
    Wow, writing a dummy test is one of the most evil things I could just imagine. Holy fuck. "We have this tool to ensure code quality, something set up with the best possible evidence that it works. You know what? Fuck that."
  • 1
    Yes, I am talking to the management exactly about this. I dug into the code base for this team and everything else they did earlier, and I am surprised. There are so many of these dummy test cases, that don’t really test anything, but exist just to provide coverage. We will require considerable manpower to write the unit tests now, given that some of the modules were written by people who left a long time ago.
  • 4
    "What the developer did was to write a dummy test case" - fire them. period.
  • 0
    @tosensei Let’s see.
  • 0
    I'm normally not one for unit tests - and my code is absolutely fine, btw - but this does strike me as an instance where it'd make sense to validate that the given test cases show correct outputs. Although I'm also wondering, how complex can/should the price of something ever be?
  • 2
    I agree which all the business logic should be covered but keeping 100% of project coverage costs a lot of time for little benefit since "plumbing" is very hard and ineffective to test
  • 2
    Yeah, developers should write unit tests. But QA should write its own automated tests. Manual testing is a waste of oxygen, that will never check everything.
  • 1
    @spongegeoff I find it difficult to imagine any sort of backend logic where writing unit tests is counterproductive. But then again I have only 3 years of experience with specific tech stacks so there is a lot I don't know.

    About the complexity, some reseller logic is very complex. Pricing has two sides, one between manufacturer and reseller, and another between reseller and customer. The pricing models are different for different items (like saas vs Hardware). Then there is inventory based logic (more auto discount on things that don't sell, etc), margins, markups. Then, based on the order of calculation the formulas change (for example, if margin is changed, should the reseller cost be changed or should the customer cost be changed). And then there is order of calculations that is user configurable, logic for rounding, multicurrency (manufacturer using USD and reseller using GBP and end customer using Euro), when to convert, when's rate, etc.

    This is just generic logic.
  • 3
    Guess I'm dead, guys.
  • 2
    What about people who commit directly on master without attempting to run code locally? Should they be instantly death ray'd?

    The answer is of course yes!
  • 1
    @PepeTheFrog ah I have an entirely separate rant for that!
  • 1
    @nanobot Well, unit tests can be counter-productive in that while you are writing them you are not producing the next thing. If you have fairly straightforward tests to validate a complex and business critical process I can see the value. Writing tests that may well be, themselves, flawed doesn't strike me as a universally good use of time - there must surely be instances in which the test is more complex than the code.
  • 1
    Sounds like the team of devs weren't experienced or competent enough to take on a project of this magnitude. I'm sure they *thought* they were, but clearly not.

    Problem is, this is likely as much management's fault, if not more so. If you go out and pay market rate for a team of decent, experienced devs and give them clear requirements and a sensible timeframe, this crap just doesn't really happen. What often does happen though is that management pays pittance for the cheapest devs they can hire, gives them some vague requirements, says they need it done yesterday, and hounds them to hand it over as fast as possible. Then they're surprised when the devs deliver trash.
  • 1
    Unit tests are almost always waste of time.
  • 0
  • 0
    @AlmondSauce maybe IDK. But I’m certain that the requirements were vague. I checked yesterday.
  • 1
    @spongegeoff the test being more complex can code is generally not so prevalent. It’s easier to take an input, put it to a code block, and match the output with an expected output then doing the actual processing. Of course if you want to test a function that adds two numbers, I agree.

    But even in that case, it helps with regression I think.
  • 0
    @nanobot developers find testing boring, fact. It is also tedious and hard to keep updated, on top of code changes. Component tests are better.
  • 1
    @aviophile I think you are right. I was not very familiar with the different terms, but it turns out that our “unit” for an unit test is generally a “module” in the code base or “component” in the product. I read up some stuff and now I understand a lot of things better (and a lot of things we are doing/calling/designing/planning wrong). Thanks for the nudge ❤️
  • 1
    @nanobot Thanks for the thoughts on unit tests - have to say I'm now more inclined to look at where I might use some.
Add Comment