Possible duplicate of Should I have unit tests for known defects?

see also: What is the value of checking in failing unit tests?

Great question - it's certainly a set of common misconceptions of what unit tests are, how they are supposed to be used and what use we're expecting from them :)

Related

Oh boy... Let me give you a car analogy: If you start the car and the "check engine" "check airbag" and "check brakes" warning lights stay on, is that good or bad? Sure, it might just be some glitch, and the warning lights won't be able to tell you if the nuts on your wheel are loose, but is that a reason to say "oh, the airbag fault light. That's fine. I don't plan on crashing today anyway."

"I would even suggest that even releasing software with failing unit tests is not necessary bad. At least then you know that some aspect of the software has limitations." It sounds like you want to embrace mediocre and buggy code rather than go through the trouble of fixing it

Just to pick up on point 4: are you expecting to write all your tests before any of the implementation? That's not a common (or successful) way to work. Normally, a developer writes a single failing test, and implements enough for that to pass before writing the next failing test. The failing test here is a Good Thing (it describes what must be changed), whereas a failing test in committed code is a Bad Thing (it identified something that used to function correctly, but no longer does).

As an exercise, try replacing the phrase "unit test" in your question with "compiler error" (or "syntax error", if there's no compiler). It's obvious that a release shouldn't have compiler errors, since it would be unusable; yet compiler errors and syntax errors are the normal state of affairs on a developer's machine when they're writing code. The errors only disappear when they've finished; and that's exactly when the code should be pushed. Now replace "compiler error" in what I wrote with "unit test" :)

There's a difference between required functionality and future goals. Tests are for required functionality: they're precise, formal, executable and if they fail the software doesn't work. Future goals might not be precise or formal, let alone executable, so they're better left in natural language like in issue/bug trackers, documentation, comments, etc.

This question completely goes against software engineering design principles...

@Azxdreuwa Yes. But this makes it an excellent question to answer. Educating people with wrong assumptions is valuable!

Another thing... Isn't all passing unit test all the time bad? Did you miss something? I think It's a bigger red flag if you haven't made updates to your unit tests in a long time.

@AndresF. Which is thankfully something good that can come from this question. I can't believe though how it has, at the time of writing, 10 votes and 3 stars. This stack is called 'software engineering', how can so many people have this assumption?

A unit test is a small contract. You do not need very many unit tests if you use a programming language that supports contracts, such as Eiffel, Ada, SPARK, D, M#. But since few people use those languages and other languages do not have contracts built into the core language, one viable alternative is to use unit tests to encode the API contracts. And the only way that unit tests work is to write them first (one-at-a-time, not all-at-once); otherwise if written in arrears they lose almost all the value proposition of writing them at all.

@Azxdreuwa I upvoted because I think it's a good question that needs to be answered, not because I agree. I suspect many others had the same reason.

You completely miss the point of unit tests: unit tests are there to make sure that when you make changes you don't accidentally break something. Or at worst, that you know it right away and can fix it immediately, while the changes are still fresh in your head. If it isn't that important, it doesn't need a unit test. If it is, well, it's important so fix it ASAP.

I’m not entirely clear what development process you’d recommend instead?

However, it seems to me that, if the components your code depends on are broken, you’d want to fix that before you try to fix the integration tests. Or nothing you build with them will work.

You seem to be considering failing tests a blame - No, they aren't. They should be considered encouragement to fix your code.

OP, you completely misunderstand so much. unit tests provide real value. the fact that you dont see that, or you dont like the hassle, doesnt mean unit tests are suddenly without value. if you were arguing unit tests versus integration tests - thats a discussion we can have. but your whole question here is opinionated, lacking in fact and really quite unknowledgable. Why dont you read up some good books on unit testing and come back with specific questions on how to improve your testing.

@vikingsteve Did you read the question? Where did I say unit tests don't provide value?

I think what you want is a test that alerts you when it starts to pass, such as a long-standing issue that might be fixed by things that you have no control over. I sometimes do this by making the test fail when things are unexpectedly working, with an obvious comment that says what to do next: like to remove a hideous workaround that is now redundant.