so glad that my job forces me to tbh. because the result is just objectively more conformant code (to be fair, those are conformance tests instead of unit tests but still unpleasant to write)
@lizzy I feel like in smth you're doing for a job then yeah you should write unit tests, but like for any of my personal projects I am not writing unit tests
ehh, I have never been convinced of their value in a couple decades of coding and watching software reliability do what it does. My lab is working on making that argument properly. tl;dr: play our cards right and it could be that copious unit tests will go the way of scheduled password rotation, in the face of static analysis.
I am not categorically against unit tests. They are needed and perform a good function. But just for the purpose of having a conversation, let me take a contrarian stance.
When we say unit tests are easy to write, mostly we mean it is very easy to write bad tests that end up some variation of: - Take value X - Give me back the value X - Is it X?
Additionally, the primary function of the vast majority of unit tests is to have to update them when the code changes.
@dawngreeter the problem with unit tests is that they are like going to the gym. If your code was always developed with unit tests, they are easy to write. But if you have code that wasn’t developed with unit tests they are hard to retrofit. And no, “we’ll just add unit tests for new code” doesn’t work either.
@BenAveling @dawngreeter Absolutely! I dealt mostly with legacy code systems where I was adding functionality or whole modules. Unit tests just didn't fit in like I needed them to.
And this is when knowing that if you are refactoring code, unit tests will help a lot in validating you "did no harm" in the rewrite.
I wish I could write self contained unit tests in 10 minutes for ngscopeclient, lol.
It's been a real challenge to come up with test cases that don't depend on huge external data files (which might be NDA restricted), have easily verifiable outputs, don't depend on external hardware, etc.
Building a hardware mock good enough to write a test case against would basically mean reimplementing its firmware bug for bug in the test bench.
- I only write infrastructure scripts I don’t need tests - Somebody told me I have to do Test Driven Development so why bother - HOW DARE YOU SUGGEST I WRITE CODE WITH BUGS
Test driven development is a thought terminating cliche and it needs to die in a fire. STOP MAKING EVERYTHING RAILS
lizzy
in reply to solo • • •solo
in reply to lizzy • • •lizzy likes this.
lizzy
in reply to solo • • •solo
in reply to lizzy • • •tomgrzybow
in reply to solo • •solo likes this.
Leon P Smith
in reply to solo • • •I don't always write test suites, but when I do, it often takes way, _way_, longer than 10 minutes.
Definitely worth doing though, and certain types of code I wouldn't even consider not writing a test suite for.
Falcon Darkstar
in reply to solo • • •Turing Incomplete
in reply to solo • • •I am not categorically against unit tests. They are needed and perform a good function. But just for the purpose of having a conversation, let me take a contrarian stance.
When we say unit tests are easy to write, mostly we mean it is very easy to write bad tests that end up some variation of:
- Take value X
- Give me back the value X
- Is it X?
Additionally, the primary function of the vast majority of unit tests is to have to update them when the code changes.
Ben Aveling
in reply to Turing Incomplete • • •Will
in reply to Ben Aveling • • •@BenAveling @dawngreeter Absolutely! I dealt mostly with legacy code systems where I was adding functionality or whole modules. Unit tests just didn't fit in like I needed them to.
And this is when knowing that if you are refactoring code, unit tests will help a lot in validating you "did no harm" in the rewrite.
Alex
in reply to solo • • •Jona Joachim
in reply to solo • • •Andrew Zonenberg
in reply to solo • • •I wish I could write self contained unit tests in 10 minutes for ngscopeclient, lol.
It's been a real challenge to come up with test cases that don't depend on huge external data files (which might be NDA restricted), have easily verifiable outputs, don't depend on external hardware, etc.
Building a hardware mock good enough to write a test case against would basically mean reimplementing its firmware bug for bug in the test bench.
The Polish Dispatch
in reply to solo • • •AN/CRM-114
in reply to solo • • •The case against writing tests:
- I only write infrastructure scripts I don’t need tests
- Somebody told me I have to do Test Driven Development so why bother
- HOW DARE YOU SUGGEST I WRITE CODE WITH BUGS
Test driven development is a thought terminating cliche and it needs to die in a fire. STOP MAKING EVERYTHING RAILS