#unit-tests

Urs introduces the below key questions in Software Development and slowly answers all of them in 45 minutes. 

I like the acronym “FIRSTRECC”:

Fast => Fast feedback, you only run them if they are fast Isolated => 1 test tests 1 thing, no cross-talk Repeatable => same outcome over and over again Self-Validating => green or red Timely => written at the right time   before: TDD, on process boundary   later: increase safety, process boundary tests   bug fixing: Defetct Driven Testing     -> the later, the harder/more difficult Refactoring friendly => code canges without changes to tests Extensible =>  adding new tests without changing existing tests Changable => keep tests clean and simple Concise => easy to read and understand

I found it interesting to learn what Urs would “test after”

I would try to write the “Process Bounday Tests” also upfront, I mean Test Driven.

See the full video here (44mins, in German)

Over the years, I've found that among advocates of TDD there is some disagreement over whether tests should be written before or after the actual code that is being tested. At least in my experience, I believe there are situations that warrant one approach over the other.

When I'm brainstorming and trying to come up with a good design, I don't want to write unit tests that might become obsolete in a couple of minutes. I want to try to solve a particular problem -- free-writing, so to speak -- in order to see if a particular design has merit. Often this will mean writing a ton of code before I write the first unit test. I think this approach is valid in this circumstance.

In contrast, when writing logic that is participating in an infrastructure that is already proven there is less need for the freedom to brainstorm. In these situations it makes sense to write the unit tests first. The reason here is what test-first TDD advocates have long stressed -- it's way harder to write unit tests for code you already think is perfect. It's easier by far to write the unit tests first, watch them fail, and then write the correct code that fixes the unit test.

The point here is that the order of writing unit tests should be predicated on the circumstances of the code that you are writing. If you are early in the design, it's quite possible you don't even know what classes you should be writing unit tests for. You're trying to figure out syntactically what would be pleasing for developers. You absolutely need the freedom to freewrite without thinking of all the ways things could succeed or fail -- in fact in this situation you're trying to see if any idea has even a chance of succeeding.

It is neither.

I don't care what a Unit Test is for you. I want to get fast feedback and have a self testing system. Maybe the next step is self-healing system?

Google uses the terms: Small, Medium, Large to avoid this whole debate.

"Without SML as a core part of the vocabulary, forcing discussion of testing concepts using fresh new terms and sidestepping both confusion and debate over the old, none of the other Testing Grouplet programs likely would have the impact they had, at least not as quickly, ... SML broke down language and conceptual barriers."

Awesome and quite very long article that every serious developer should read! I especially like how Mike Bland writes unit tests for 2 bugs that turned up recently: "gotoFail" and "Heartbleed". And the experience report about "How to change the Culture @ Google" is just gold!

Lots of great quotes: When writing unit tests...

Don't think about yourself today, think about yourself tomorrow, about your fellow programmers, your users, and society.

The burden of maintaining mocks is by far the most common argument against mockist tests. You have to write both the implementation and at least one test double. When one changes, the other has to change too.

Perhaps most troubling, if an object's interface changes, its dependencies' unit tests will continue to pass because the mock objects will function as always — arguably a hinderance to refactoring. Since you need to test for that scenario, mockists also write integration tests. Integration tests are probably a good idea anyway, but as a mockist, you don't really have a choice.

[...]

Учёба в институте, она как написание юнит-тестов во время разработки.

Кто-то считает написание юнит-тестов жизненно необходимым, а кто-то считает что это ненужная трата времени.

Кто-то пишет их осознанно, а кто-то чисто как формальность (просто чтобы было).

Написание юнит-тестов требует времени и заранее сложно сказать, тратится это время с пользой или нет (если не рассматривать вопросы “религии”).

Некоторые, написав юнит-тесты, больше никогда ими не пользуются.

Иногда, необходимость написания юнит-тестов продиктована сверху.

Некоторые люди спохватываются писать юнит-тесты слишком поздно. И, зачастую, это всё равно приносит свои плоды.

Юнит-тесты не цель, а средство достижения цели.

Don steps through Unit-Testing, TDD and BDD to help us write maintainable high-quality code. Who doesn't want that? 

Questions to consider:

Should you test private methods?

Should you test every getter/setter?

What changes when you call your tests, "behaviours"?

Find the recording and many more on the Scrum.org webcast website