I find this very important because in this semester for our Administration of Software Projects class we had to cut the scope of our project due to constant bugs, there existing no tests, and the team being unfamiliarized with the technologies that were imposed to us by the teacher. Testing can really reduce the impact of bugs and reduce the constant increase of the cost-time curve of changes in the project.

Unit testing is of course better than code inspectors, because code inspectors only check if the code makes sense, whilst they are not specialized for exactly what it is the program is trying to achieve.

All programmers should read this blog, it opens your eyes to the importance of testing.

I think that overall this article's title comes off a bit strong, but there is reasoning behind it. I agree with what the author says, and why it is utterly stupid to program without using unit tests to check for correct functionality in your code.

I think this title overall describes something that really got my attention, as how it is totally true, and most bugs happen because we programmers are lazy to thoroughly do our code and end up creating bugs because of that.

Great explanation and examples for the do's and dont's of testing.

I think that this refers to one of the greatest misconception of testing, and one of the reasons why people don't do it. Doing testing is apparently more work and code, that's why a lot of developers avoid the practice. However, it reduces significantly the debugging time, which is, as he says in the same paragraph, "most of the effort we spend on code".

I can really say that this can save lots of time and work for the future you.

This is so true, and many people wont see it. And many will think that they must know it, but we can and will keep learning.

For this part I think there are people that enjoy findind and fixing mistakes.

I can really relate to this. Some people dont think this is right.

This is something i honestly haven't thought about while testing with JUnit, we only know if the output is the same as the expected one but we never know if the program is in a state of error and i think this is really usefull to better test programs.

This is so interesting and true. But, actually you know sometimes that certain functions or methods could fail in come cases but you know you don't know how to fix them. Wouldn't this be part of this hypothesis?

What could possibly be done with current software industry practices, like Scrum, where changes are constant and expected, in respect to changing tests to match new outputs?

When this happens, how do developers solve it? Not everyone is at the testing framework level.

If the same fixture can be applied to many test cases, can a test case use more than one fixture?

I'm understanding that it's possible to test multiple instances, but this sentence confuses me a little. How many tests can we run one after the other without getting stuck?

Is performance usually a big concern within testing?

What if the errors that you are checking for actually come from a fault in the code? Would that be unanticipated or simply a failure to your testing?

If the broadness of the thing we are testing overwhelms us. Should we stop thinking in TDD to see if something comes up? or, is declaring with fixtures that you are not testing everything is the right way?

It is tempting to write a whole set of test cases, but when tests interact with each other by sharing common features/values, the whole test set might not work because of another test case. Leading to more debugging.

This seems to be helpful when there is more than one tester in the project.

What is the correct way to run a testcase so that teardown and setup are executed when encapsulated?

Is this more related to debugging rather than unit testing?

Ca we guarantee full stability by making this?

Is this the most effective way to do it ?

Is this somehow related to the coverage concept?

Is this recommendation for unit testing in general or only for this framework?

What does Kent mean here when he uses the word brittle?