Я хочу поблагодарить Стивена Колберта за то, что он придумал слово, которое я могу использовать в своем названии. Без него все это было бы возможно, если бы я не сдался в поисках лучшего слова через несколько минут.
Тесты о доверии. Мы ожидаем, что они будут надежными. Надежные тесты говорят нам, что все в порядке, когда они проходят, и что что-то не так, когда они терпят неудачу.
Проблема в том, что жизнь не черно-белая, а тесты не просто зеленые и красные. Тесты могут давать ложноположительные (неудачные, если они не должны) или ложно отрицательные (проходящие, если они не должны) результаты. Мы уже сталкивались с ложноположительными — это хрупкие, зависимые тесты.
Те, которые проходят, а не терпят неудачу, являются проблемными. Они скрывают реальную картину от нас и подрывают наше доверие не только к этим испытаниям, но и к другим. В конце концов, когда мы обнаружим проблемные тесты, кто скажет, что другие, которые мы написали, также не являются проблематичными?
Истина (насколько мы чувствуем тесты надежны) вступает в игру.
Пример внедрения зависимости
Или, скорее, внедряя пример зависимости.
Допустим, у нас есть служба (или сторонняя библиотека), которую использует наш протестированный код. Это медленно и общение ненадежно. Все вещи, которые дают услуги плохое имя. Наша естественная тенденция состоит в том, чтобы высмеивать сервис в тесте. Посмеиваясь над сервисом, мы можем тестировать наш код изолированно.
Итак, в нашем случае, наш протестированный гостиничный класс использует Сервис:
|
1
2
3
4
5
6
7
8
|
public class Hotel{ public string GetServiceName(Service service) { var result = service.GetName(); return "Name: " + result; }} |
Чтобы узнать, работает ли метод правильно, мы напишем этот тест:
|
1
2
3
4
5
6
7
8
|
[TestMethod]public void GetServiceName_RoomService_NameIsRoom(){ var fakeService = A.Fake<Service>(); A.CallTo(() => fakeService.GetName()).Returns("Room"); var hotel = new Hotel(); Assert.AreEqual("Name: Room", hotel.GetServiceName(fakeService));} |
И все отличное.
Пока в работе служба не отключится и не выдаст исключение. И наш тест говорит «Bbb-но, я все еще прохожу!».
Истина там
Насмешка — это пример препятствования реальному поведению предписывающими тестами, но это всего лишь пример. Это может случиться, когда мы тестируем несколько случаев, но не покрываем другие.
Вот один из моих любимых примеров. Что за скрытый тест?
|
1
2
3
4
|
public int Increment(){ return counter++;} |
Тесты являются примерами кода. Они работают в меру нашего воображения «что может пойти не так?» Как переполнение, в последнем случае.
Как и дифференциация , правдивость не может быть исследована сама по себе. Пример работает, но он скрывает случай, для которого нам нужен еще один тест. Нам нужно взглянуть на набор тестовых случаев и посмотреть, охватили ли мы все.
Решение не должно быть тестом того же типа. У нас может быть модульное тестирование для успешного пути обслуживания и сквозное тестирование для случая отключения. Конечно, если вы можете в первую очередь подумать о других случаях, то почему бы не протестировать их?
Итак, чтобы выровнять свою правдивость:
- Идеально Прежде чем писать тесты, а если вы делаете TDD — код, напишите список тестовых случаев. На тетради, доске или моей любимой: пустые тесты.
- Отражать Часто, когда мы пишем несколько тестов, на ум приходят новые тесты. Наличие визуального изображения кода может помочь подумать о других случаях.
- Остерегайтесь насмешек . Мы используем mocks, чтобы предписывать поведение зависимости в определенных случаях. Каждое издевательство, которое вы делаете, может быть потенциальной ошибкой, поэтому подумайте о других случаях, чтобы высмеивать.
- Рассмотрение. Делай это парами. Четыре глаза лучше, чем два.
Стремитесь к более высокой правдивости. Более высокое доверие к вашим тестам поможет вам лучше спать.
| Ссылка: | Атрибут теста №8 — Истина от нашего партнера по JCG Джила Зильберфельда в блоге Geek Out of Water . |