The existing answers are certainly good, but I have not seen anyone address this foundational misconception in the question:
at any point in time all unit tests must pass
No. Most assuredly, this will not be true. While I am developing software, NCrunch is most often either brown (build failure) or red (failed test).
Where NCrunch needs to be green (all tests passing) is when I am ready to push a commit to the source control server, because at that point others may take a dependency on my code.
This also feeds into the topic of creating new tests: tests should assert the logic and behavior of the code. Boundary conditions, fault conditions, etc. When I write new tests, I try to identify these "hot spots" in the code.
Unit tests document how I expect my code to be called - preconditions, expected outputs, etc.
If a test breaks following a change, I need to decide whether the code or the test is in error.
As a side note, unit testing sometimes goes hand-in-hand with Test Driven Development. One of the principles of TDD is that broken tests are your guideposts. When a test fails, you need to fix the code so the test passes. Here is a concrete example from earlier this week:
Background: I wrote and now support a library used by our developers that is used to validate Oracle queries. We had tests that asserted that the query matched some expected value, which made case important (it's not in Oracle) and merrily approved of invalid queries as long as they completely matched the expected value.
Instead, my library parses the query using Antlr and an Oracle 12c syntax, and then wraps various assertions on the syntax tree itself. Things like, it's valid (no parse errors were raised), all its parameters are satisfied by the parameter collection, all the expected columns read by the data reader are present in the query, etc. All of these are items that have slipped through to production at various times.
One of my fellow engineers sent me a query on Monday that had failed (or rather, had succeeded when it should have failed) over the weekend. My library said the syntax was fine, but it blew up when the server tried to run it. And when he looked at the query, it was obvious why:
UPDATE my_table(
SET column_1 = 'MyValue'
WHERE id_column = 123;
I loaded up the project and added a unit test that asserted that this query should not be valid. Obviously, the test failed.
Next, I debugged the failing test, stepped through the code where I expected it to throw the exception, and figured out that Antlr was raising an error on the open paren, just not in a way the previous code was expecting. I modified the code, verified that the test was now green (passing) and that none others had broken in the process, committed, and pushed.
This took maybe 20 minutes, and in the process I actually improved the library significantly because it now supported an entire range of errors that previously it had been ignoring. If I did not have unit tests for the library, researching and fixing the issue could have taken hours.
