Моки и стабы

Сам понял, что ступил — тут же сильная типизация и язык компилируемый — компилятор ошибку выдаст. Слаботипизированные интерпретируемые языки заставляют строже к тестам относиться.

Я правильно понимаю, что вы покрываете тестами и подобный код:

class MyClass
{
private object someData;

pulbic MyClass(object someData)
{
if (someData == null)
throw new ArgumentNullException("someData");

this.someData = someData;
}

public override string ToString()
{
return someData.ToString();
}
}


И теперь в тесте:
[Test(ExpectedException(typeof(ArgumentNullException))]
public void MyClass_Constructor_Failure()
{
var myClass = new MyClass(null);
}

[Test]
public void MyClass_Custructor_Success()
{
var myClass = new MyClass(new object());
}

[Test]
public void MyClass_ToString_CallsObjectToString()
{
object o = new object();
var myClass = new MyClass(o);
Assert.AreEquals(myClass.ToString(), o.ToString());
}


Ведь если этого не сделать, то 100% покрытия тестами у вас не будет:) Я, например, первый вариант предпочитаю «проверять» с помощью контрактов и статического анализатора, в результате, если что-то пойдет не так, то у меня код просто не скомпилится (ну, скомпилится, но я ошибку я увижу во время компиляции). Кроме того, натравите на свой собственный код какой-нить анализатор, у вас ведь тоже не 100%;)

Я продолжу свою мысль (не столь категоричную, как вашу): тестов должно быть _достаточно_.

Знаете, что самое интересное: Кент Бек — небезызвестный папа TDD, не является фанатом 100% покрытия тестами (пруф в подкасте от SERadio). Не все тесты приносят что-то полезное, они могут и захламлять код тестов, пряча при этом за грудой ненужных тестов парочку важных, которые найти в подобном хаосе будет не просто.

Так что да, я не хочу идеального качества, потому что идеальное качество требует бесконечного количества усилий для его достижения;) Прагматизм рулит и юнит-тесты в этом вопросе не исключение.