How we have unit testing philosophy? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this questi开发者_StackOverflow中文版on will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

Hi stackoverflow family.

It is doubtless that unit testing is of great importance in software development. But i think it is practice and philosophy which is test first. And majority of developers want to use this philosophy, but they can't perform it on their project because they aren't used to Test Driven Development. Now my question is for those who follow this philosophy. What are the properties of the good test according to your experiences? And how you enable it to be a part of your lives.

Good days.

---

The way of Testivus brings enlightment on unit testing.

• If you write code, write tests.
• Don’t get stuck on unit testing dogma.
• Embrace unit testing karma.
• Think of code and test as one.
• The test is more important than the unit.
• The best time to test is when the code is fresh.
• Tests not run waste away.
• An imperfect test today is better than a perfect test someday.
• An ugly test is better than no test.
• Sometimes, the test justifies the means.
• Only fools use no tools.
• Good tests fail.

---

Some characteristics of a good test:

• its execution doesn't depend on context (or state) - i.e. whether it's run in isolation or together with other tests;
• it tests exactly one functional unit;
• it covers all possible scenarios of the tested functional unit.

---

The discussion cannot be better phrased.

http://discuss.joelonsoftware.com/default.asp?joel.3.732806.3

http://discuss.joelonsoftware.com/default.asp?joel.3.39296.27

As per the idea of good test, it is one which catches a defect :).But TDD is more than defect catching, it is more about development and continuity.

---

I always think the rules and philosophy of TDD are best summed up in this article by Robert C. Martin:

The Three Rules of TDD

In it, he summarises TDD with the following three rules:

• You are not allowed to write any production code unless it is to make a failing unit test pass.
• You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
• You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

There is an implied fourth rule:

• You should refactor your code while the tests are passing.

While there are many more detailed examples, articles and books, I think these rules sum up TDD nicely.