Каковы лучшие практики в ваших тестах?

Question

Я хотел бы знать, какие у вас практики, когда вы тестируете свои классы.

Например, я люблю использовать наследование со своими приборами. Учитывая два класса BaseClass, SubClass, я делаю два других класса BaseClassFixture и SubClassFixture (SubClassFixture является подклассом BaseClassFixture). Поэтому я уверен, что я не нарушаю код, который использует SubClass в качестве BaseClass (и люди, которые расширяют мой класс, могут быть уверены, что они все делают правильно, создав еще один подкласс моего прибора).

Я также занимаюсь наследованием с интерфейсами. Например, когда я создаю фикстуру для IList, я проверяю, что любой Add, увеличивает Count на единицу. Когда у меня есть конкретный класс, который реализует IList, я просто создаю приспособление с именем MyConcreteClassIListFixture.

В этом случае приспособление для моего интерфейса является абстрактным, и я позволил своему подклассу создать экземпляр для моих тестов.

Я думаю, что это своего рода дизайн по контрактам (см. Бертран Мейер), потому что я проверяю инвариант до и после любых испытаний.

Я делаю это особенно с опубликованными интерфейсами или классами.

А вы ... каковы ваши практики ??

Answer 1

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

Для модульных тестов они должны строго подчиняться разделению проблем. Для интеграционных тестов я уделяю особое внимание тому, чтобы они следовали наиболее важному правилу.

Кроме того, тесты должны максимально соответствовать правилу СУХОЙ вместе с кодом.

Answer 2

Есть несколько важных вещей при написании юнит-теста.

1) Юнит-тесты должны быть независимыми:

Модульные тесты должны быть независимыми. Это означает, что ваш модульный тест не должен зависеть от внешних вещей для запуска. Это включает в себя подключение к интернету, внешние веб-сервисы и т. Д.

2) Модульные тесты должны быть быстрыми:

Модульные тесты должны выполняться быстро. Вы можете написать модульные тесты несколькими способами. Некоторые из них включают доступ к данным, даже если вам не нужен доступ к данным для запуска теста. Вы всегда можете использовать макет объектов и макет слоя доступа к данным.

3) Хорошее соглашение об именах:

Юнит-тесты должны иметь хорошее соглашение об именах и должны читаться как истории.

Вот один пример:

открытый класс when_user_transfer_money_from_source_account_to_destination_account

public void make_sure_error_is_thrown_when_source_account_has_insufficient_funds () {

} * * тысяча двадцать-один

Вот хороший скринкаст, который охватывает многие из вышеперечисленных пунктов:

http://screencastaday.com/ScreenCasts/32_Introduction_to_Mocking.aspx