Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
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.
-
@tosensei Let’s see.
-
@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. -
@PepeTheFrog ah I have an entirely separate rant for that!
-
@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.
-
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. -
@aviophile Example?
-
@AlmondSauce maybe IDK. But I’m certain that the requirements were vague. I checked yesterday.
-
@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. -
@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 ❤️
when your code is a mess but everything work out in the end
When you keep getting +1s on a rant you posted a month ago.
Go big or go home.
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.
rant
unit tests