Why you should write tests first - Uncle Bob

Imagine doing a 3d game play doing unit tests before...

Maybe. Or you can just write decoupled code without the tests.

It's funny because it's true 😅

If you don't trust your code, why do you trust your tests? Shouldn't your tests be written by other people?
Otherwise you're like these lock companies who engineer unpickable locks and then LPL comes and uses a soda can

Not all code needs to be decoupled, or even benefits from being decoupled. I think Bob should talk more about the essences of different types of code and how different they are. For example core is completely different from peripheral. There are differences in how often they change, centrality/position in design, impact on performance (hot vs cold code), how they interact with the OS and hardware (i.e. the real world), knowledge on domain, etc.

Uncle Bob, confusing and complicating the Software Industry since the 90s. Guess what he's doing recently? Functional programming. Yep, he ditched OOP after all the chit chat and books sold.

Guys, Software Engineering is not about general rules or cult of personalities. Every problem is different, and the principles, yet valid, are only tools and are optional. That is why is so hard.

I write all my tests first. People always say “but my special type of software can’t be tested” yet I’ve found complex things that can be tested - test first

In fact, James Grenning has a fantastic book on Tdd for embedded systems

The main benefit of writing tests, as I see it, is that you are creating a canonized list of expected behaviors for your API. Consumers can trust that your API will work if it is used as described in the tests. Any changes that break those behaviors will also cause your tests to fail. If you have a test that asserts that method A returns value B when passed parameter C, any code that breaks this expected behavior so now the method is returning value D, will also break that test. The engineer making this change will know they broke this behavior before they can push their code and break that behavior for every one of their consumers.

The benefit of writing tests first is the same but in reverse. If you write that test before implementing method A, you'll know you're done implementing the method when the test passes. And, if in the future you need to refactor A for whatever reason, you can do so with the assurance that you will not break the behavior that you have canonized in your tests without knowing it. This makes it easier to develop quickly early on without spending too much time worrying about optimization before it's appropriate, and makes future optimization safer and easier.

Tests also act as a sort of second layer of defense against runtime errors after type checking. A function's call signature can ensure that you don't pass a string to a function expecting a number, but a test can ensure that if you pass a negative number to a function that expects a positive non-zero number, you will be given an actionable error.

Writing tests has the added benefit of making collaboration easier. If you're reviewing someone's code or even editing it some time in the future, you can get a high level understanding of what it is meant to do by reading the tests. Rather than writing comments which can easily become out of sync with the code they are describing, you can add those details as the test names. If the behavior changes, the test will change, and it will be clear that the test name will need to change as well. A comment saying "this function is invalid when applied to negative numbers" above an exception becomes a test, "throw error when passed a negative number" that asserts this exception is thrown as expected. In this example you might even keep the comment but the test ensures that behavior works in a way the comment can't.

This bit is a tad extreme and not something I would suggest as a standard, but in my own projects, I've taken to writing the kinds of comments you might place inside a function explaining or justifying a part of its implementation (like the one above) inside my tests instead. If I think it's worth adding a comment explaining why we throw an exception, I do so in the test that ensures and demonstrates that the exception is thrown. If that exception is no longer necessary, the test will need to be removed and so I know that comment which is no longer correct will be removed along with it.

Software is soft because it is easy to change. Tests make software harder to change. Keep software soft.

Damn, empathy driven development... He just FEELS the code like many of us do. Love it <3

Dear Uncle Bob, most unit tests are waste. We know this after Coplien revealed this fact to us. Talking about a test suite is a bad sign there might be too many tests. There are many ways to achieve quality.

I've been writing code for at least as long as "Uncle Bob" has. I've watched several of his videos now. He's full of shit.

I hate test-driven development because it feels like you’re coding just to make the tests work, instead of focusing on the actual logic or the big picture. Don’t get me wrong, having tests is important, but I think they should focus more on integration and making sure the outcome is correct.