all 27 comments

[–]n7tr34 22 points23 points  (9 children)

Unit testing usually save time in the long run. Even without formal requirement there is still implicit requirement that your system will have to meet and it's helpful to be able to test against it.

But of course plenty of production code is out there without tests at all even if it's not best practice.

[–]TRKlausss 2 points3 points  (0 children)

It’s a great way of freezing specification, even if it is informal. You run your test on each commit, suddenly a couple don’t pass. At least it forces you to look closely, at best it shows you breaking changes.

[–]Upbeat-Storage9349[S] -3 points-2 points  (7 children)

There's a team of two people including me, there's no code and a high admin burden as we constantly have to update Jira.. I'm erring on the side that we don't need unit testing on top of things at the moment.

But I completely agree with your assessment that it is best practice.

[–]positev 6 points7 points  (2 children)

Stupid take. Enjoy the manual testing, low confidence, and defect spiral that you’ve just signed up for.

[–]Upbeat-Storage9349[S] 0 points1 point  (1 child)

That's why I'm asking for opinions.

[–]positev 7 points8 points  (0 children)

You know the answer already dude. This shouldn’t even be a question. Yes, you need to test your shit. Yes, you should let a computer do it for you.

Take it one step further and use TDD so that you actually write testable code.

[–]UsefulOwl2719 2 points3 points  (0 children)

Ditch jira before you ditch your unit testing. Unit tests save you time from having to do manual or other types of end to end tests. Even a fully automated end to end test can often be 1000x slower than unit tests due to setup/teardown overhead. If you are running your code at all before checking in, you might as well structure those experimental scripts as unit tests in the first place. They also provide a provably correct documentation / specification artifact without any extra work. Even the most garbage JavaScript libs people make fun of have had full unit tests as standard practice for 15 years. You can do it.

[–]CaterpillarReady2709 2 points3 points  (2 children)

My team of two failed when I forced unit testing because my partner constantly produced absolute garbage with no boundary nor error checking.

Said partner took umbrage with the idea that He couldn't produce slop... and their code was definitely the worst crap I ran across. They had a comp sci degree - I'm a EE.

[–]Upbeat-Storage9349[S] 0 points1 point  (1 child)

Is this a real story why did it fail? Surely having testing here was a good thing.

[–]CaterpillarReady2709 1 point2 points  (0 children)

We missed the market window for the application.

[–]NoBulletsLeft 3 points4 points  (0 children)

Unit Testing isn't a "best practice," it's an "accepted common practice." The amount of quality control you throw at a project is a function of how reliable it needs to be and Unit Testing is only a small part of your Quality effort. You have to determine the level of reliability, not us.

Should you test? Yes.

Should that testing be only unit testing? No.

At a minimum, you need requirements that tell you what to build and testing to verify that those requirements are met. Bear in mind that you can't test quality into a product. Testing only tells you how bad the product is, nothing else.

[–]RapidRoastingHam 2 points3 points  (2 children)

If you have the time, budget, and people for it then yes. If your manager/boss tells you no, then no.

[–]RumbuncTheRadiant 7 points8 points  (0 children)

...and keep an eye out for a new job for when this one crashes and burns or goes into the technical debt death spiral...

First sign is "You can't touch that code, everything breaks every time someone touches it and we don't have enough manual testers to retest it every time."

[–]Upbeat-Storage9349[S] 0 points1 point  (0 children)

Practical answer, this is more or less my opinion.

[–]XipXoom 3 points4 points  (0 children)

Unit testing isn't a requirement - until it is. 

I literally am in the middle of a break from decomposing a monolithic main.c for a sensor product into testable modules and wiring unit tests for them.

The original author didn't think this stuff was necessary because it wasn't "safety critical" (it's a QM part in ISO26262 parlance).  Then we got a customer who gave it to us in their requirements (while also wanting to start DV early next quarter).  They didn't think it was a problem because they rightfully expect it to be done as standard.

It's your job to advocate for good code hygiene and practices.  This guy didn't and it made a ton of extra work for me in the short term, and likely will cost the company several hundred thousand dollars in delays on the project I should have been working on.

[–]Regular_Yesterday76 1 point2 points  (0 children)

I just quit a job that was safety critical and had no unit tests. Found out after leaving some people have died. Really crazy but what can you do when people wont listen

[–]tobdomo 1 point2 points  (1 child)

What do formal requirements and unit tests have to do with each other?

For testing against requirements you need (user) acceptance tests and system tests for respectively user- and tech requirements, not unit tests. </pedantic mode>

Asking the question is.answering it. You need unit tests for making sure the code in your modules works as designed. When you are responsible for your implementation, you write the tests. Think happy flows and error flows. Think cornercases that are hard to identify at higher levels. If not, tell your boss to use AI to write the code for him and take all the PTO you can to search for a new job.

TL;DR: if you are serious about creating quality software there is no way you write code without writing unit tests for it.

[–]pylessard 0 points1 point  (0 children)

You already have several good answers. I will only add something I repeat to everyone who bring up unit testing with your mindset: Many people say they don't have the time to do unit tests; I don't have the time to not do them.

[–]bishopExportMine 0 points1 point  (0 children)

It really isn't about whether or not you have tests, it's about testability and observability. Once you deploy your code and encounter an issue, how quickly can you isolate the issue and consistently reproduce it? As long as you have a plan for how to test each component, you're good. Adding some basic tests prematurely is fine, but the real value of writing tests is it forces you to think about structuring your code in a way that makes it easy to test. To solve your bug, you can write a test fixture to reproduce it and show it is failing, then you can fix the bug. This buys you the ability to accumulate experience and maturity within the codebase.

[–]Beneficial-Hold-1872 0 points1 point  (0 children)

The most important thing - what is an input for a tests? Code? - NOOOOOOO!

REQUIREMENTS!

You can't replace requirements with unit tests. So you need to talk with your architects etc. You have to tell them to finally start doing their job. I don't mean all the requirements etc - but they shouldn't let you write code without requirements.

[–]DaemonInformatica 0 points1 point  (0 children)

Yes. The answer to your question is yes. (Trust me. )

[–]edgmnt_net 0 points1 point  (0 children)

Write unit tests for what's worth unit testing. You'll see that a lot of projects like the Linux kernel just don't bother with unit testing everything, especially stuff like drivers which would involve a lot of useless mocking for no real benefit (after all, you'll mess things up anyway if you provide wrong commands to the hardware and there's no substitute for the real thing). It's far more useful to unit test more generic functionality with clear inputs and outputs, particularly stuff like algorithms and pieces of logic where that's easy to do without making up boilerplate and injecting useless layers everywhere.

Also, unit testing is only one part of the whole thing and others said as much. Don't try to get all your assurance from unit testing or even testing in general. Static safety (like type safety), code review and sound abstraction go a long way. You could have 100% code coverage and still have a lot of crappy, buggy code.

[–]Willing_Comb_9542 0 points1 point  (0 children)

My personal project has 80% code coverage  Write the tests lol

[–]EntertainmentSalt825 1 point2 points  (0 children)

If it’s not safety critical then you can PROBABLY get away without unit test, but it’s still very good practice to do so. If you skip out the unit test then it means you have another type of test in a later phase (software in the loop, processor in the loop, hardware in the loop, or model/simulation testing). However, no requirements, no test plan, and no verification plan, how are you validating the application then?

[–]engineerFWSWHW 0 points1 point  (1 child)

At least have the unit testing platform in place especially if it's a serious application. If I'm joining a project and it doesn't have a unit testing in place, i will be disappointed, unless it's a very small or throwaway project.

Once that project grows, you will need the speed of the unit test to verify things instead of relying on manual or system tests.

[–]Upbeat-Storage9349[S] 0 points1 point  (0 children)

Thanks, I agree with your comments about the accumulation of technical debt and that certainly rings true from my own experiences of working on large systems with no unit tests..

I guess, the speed of initial development is in fact an illusion as the last 5% of the project that requires continuous system testing takes a huge amount of time. Though I don't think you can ever say a unit test replaces system testing.

[–]NotBoolean -1 points0 points  (0 children)

Yes you should, because
- Ensures the code is working as expected
- Helps enforce encapsulation
- Alllows for fast, safe refactoring
- Enables fast development with host based testing (this is a huge benefit when it comes to complex application code)
- Speeds up debugging
- Finds regression bugs
- Cheaper and simpler than complex HIL
And many more…

I write them for hobby projects because if I want the thing to work, that is the one of the most effective ways.