TDD - Когда это должно хорошо записать непровальный тест?
Использование @:nativeGen и зависящей от платформы функции печати (вместо специфичной для Haxe, требующей информации о местоположении) обычно является хорошим началом,
@:nativeGen class Main {
static function main() {
cs.system.Console.WriteLine("hi!");
}
}
public class Main {
public Main() {
}
public static void main() {
global::System.Console.WriteLine(((string) ("hi!") ));
}
}
Как уже упоминалось, многословие варьируется в зависимости от платформы - например, Haxe-> JS или Haxe-> AS3 создает довольно написанный от руки код, в то время как Haxe-> C # и Haxe-> C ++ включают множество неявных приведений, чтобы исключить любой риск двусмысленности кода.
Можно использовать API CustomJSGenerator от Haxe для написания пользовательских генераторов для языков, отличных от JS (и преобразования кода для соответствия соглашениям / многословию) - например, я создал Haxe-> GML (сценарий язык, напоминающий смесь генератора плоских C и JS), и позволил ему очень близко соответствовать исходной структуре: 
12 ответов
Существует две причины записи проваливающих тестов сначала и затем создания их выполнены;
Первое должно проверить, тестирует ли тест на самом деле то, для чего Вы пишете это. Вы сначала проверяете, перестало ли это работать, Вы изменяете код для создания тестового прогона затем, Вы проверяете, работает ли это. Это кажется глупым, но у меня было несколько случаев, где я добавил тест для кода, который уже работал, чтобы узнать позже, что я сделал ошибку в тесте, который заставил его всегда работать.
Вторая и самая важная причина состоит в том, чтобы препятствовать тому, чтобы Вы писали, что слишком много тестирует. Тесты отражают Ваш дизайн, и Ваш дизайн отражает Ваше изменение требований и требований. Вы не хотите должными быть переписывать много тестов, когда это происходит. Хорошее эмпирическое правило состоит в том, чтобы иметь каждый тестовый сбой только по одной причине и иметь только один тестовый сбой по этой причине. TDD пытается осуществить это путем повторения стандарта red-green-refactor цикл для каждого теста, каждой функции и каждого изменения в кодовой базе.
Но конечно правила сделаны быть нарушенными. Если Вы имеете в виду, почему эти правила сделаны во-первых, можно быть гибкими с ними. Например, когда Вы находите, что у Вас есть тесты, которые тестируют больше чем одну вещь, можно разделить ее. Эффективно Вы записали два новых теста, что Вы не видели сбоя прежде. Повреждение и затем фиксация Вашего кода для наблюдения нового тестового сбоя являются хорошим способом проверить вещи дважды.
Я сомневаюсь, что любой рекомендовал бы, чтобы я потратил впустую время для реализации нестабильного алгоритма сортировки только для тестирования тестового сценария, затем повторно реализовал сортировку с объединением. Как часто Вы сталкиваетесь с аналогичной ситуацией и что Вы делаете?
Позвольте мне быть тем, рекомендуют это затем.:)
Весь этот материал является компромиссами между временем, которое Вы проводите, с одной стороны, и риски Вы уменьшаете или смягчаете, а также понимание, что Вы получаете, с другой стороны.
Продолжение гипотетического примера...
Если "устойчивость" является важным свойством/функцией, и Вы "не тестируете тест", заставляя ее перестать работать, Вы экономите время выполнения той работы, но подвергаетесь риску, что тест является неправильным и всегда будет зеленым.
С другой стороны, при действительно "тестировании теста" путем повреждения функции и наблюдения, что это перестало работать, Вы снижаете риск теста.
И, подстановочный знак, Вы могли бы получить некоторый важный бит знания. Например, при попытке кодировать 'плохой' вид и заставить тест перестать работать, Вы могли бы думать более глубоко об ограничениях сравнения на тип, который Вы сортируете и обнаруживаете, что использовали "x == y" как предикат класса эквивалентности для сортировки, но на самом деле"! (x <y) &&! (y <x)", лучший предикат для Вашей системы (например, Вы могли бы раскрыть ошибку или недостаток дизайна).
Таким образом, как я говорю, допускают ошибку на стороне, 'проводят дополнительное время, чтобы заставить его перестать работать, даже если это означает намеренно повреждать систему только для получения красной точки на экране на мгновение', потому что, в то время как каждая из этих небольших "диверсий" несет расходы некоторого времени, время от времени каждый сохранит Вас огромный пакет (например, ой, ошибка в тесте означает, что я никогда не тестировал самое важное свойство своей системы, или ой, наш целый дизайн для предикатов неравенства испорчен). Это похоже на проигрывание лотереи, кроме разногласий в Вашу пользу в конечном счете; каждую неделю Вы тратите 5$ на билеты, и обычно Вы проигрываете, но один раз в три месяца Вы выигрываете джекпот за 1 000$.
Одно большое преимущество для того, чтобы заставлять тест перестать работать сначала состоит в том, что это гарантирует, что Ваш тест действительно тестирует то, что Вы думаете. У Вас могут быть тонкие ошибки в Вашем тесте, которые вызывают его к не, действительно тестируют что-либо вообще.
Например, я однажды видел в нашей кодовой базе C++, кто-то регистрируется в тесте:
assertTrue(x = 1);
Очевидно они не программировали так, чтобы тест, неудавшийся сначала, так как, это не тестировало ничего вообще.
Простое правило TDD: Вы тесты записи, которые могли бы перестать работать.
Если разработка программного обеспечения сказала нам что-нибудь, случается так, что Вы не можете предсказать результаты испытаний. Даже сбой. Мне на самом деле довольно свойственно видеть "запросы новой возможности", которые уже, оказывается, работают в существующем программном обеспечении. Это распространено, потому что многими новыми возможностями являются простые расширения существующих бизнес-требований. Базовая, ортогональная разработка программного обеспечения будет все еще работать.
Т.е. Новая возможность "Список X должна содержать до 10 объектов" максимум вместо "5 объектов", потребует нового тестового сценария. Тест передаст, когда фактическая реализация Списка X позволит 2^32 объекты, но Вы не знаете, что наверняка, пока Вы не запускаете новый тест.
Ядру TDDers говорил бы Вас всегда, нужен провальный тест, чтобы проверить, что положительный тест не является положительной ложью, но я думаю в действительности, что много разработчиков пропускает провальный тест.
Если Вы пишете новую часть кода, Вы пишете тест, то код, Это означает, что в первый раз у Вас всегда есть провальный тест (потому что это выполнилось против фиктивного интерфейса). Затем можно несколько раз осуществлять рефакторинг, и в этом случае Вы, возможно, не должны писать дополнительные тесты, потому что тот, который Вы имеете, может быть уже достаточно.
Однако можно хотеть поддержать некоторый код с методами TDD; в этом случае Вы сначала имеете к тестам записи, поскольку характеристика тестирует (который по определению никогда не перестанет работать, потому что они выполняются против рабочих интерфейсов), затем осуществите рефакторинг.
Существуют причины для тестов записи в TDD вне просто, "тестируют сначала" разработку.
Предположим, что Ваш метод сортировки имеет некоторые другие свойства вне прямого действия сортировки, например: это проверяет это, все исходные данные являются целыми числами. Вы первоначально не полагаетесь на это, и это не находится в спецификации, таким образом, нет никакого теста.
Позже, если Вы решаете использовать это дополнительное поведение, необходимо записать тест так, чтобы кто-либо еще, кто приезжает и осуществляет рефакторинг, не повреждал это дополнительное поведение, на которое Вы теперь полагаетесь.
мм... я считал цикл TDD как
- запишите тест сначала, который перестанет работать, потому что код является просто тупиком
- напишите код так, чтобы тест передал
- осуществите рефакторинг по мере необходимости
нет никакого обязательства продолжать писать тесты, которые перестали работать, первые сбои, потому что нет никакого кода, чтобы сделать что-либо. точка первого теста должна выбрать интерфейс!
Править: Кажется, существует некоторое неверное толкование "red-green-refactor" молитвы. В соответствии со статьей TDD Википедии
В разработке через тестирование каждая новая возможность начинается с записи теста. Этот тест должен неизбежно перестать работать, потому что он записан, прежде чем опция была реализована.
Другими словами, тест должен-сбоя для новой возможности, не для дополнительного покрытия!
Править: если Вы не говорите о записи регрессионного теста для репродуцирования ошибки, конечно!
Примером, который Вы обеспечили, является IMO одно из надлежащих времен для записи теста, который передает первую попытку. Цель надлежащих тестов состоит в том, чтобы зарегистрировать ожидаемое поведение системы. Нормально писать тест, не изменяя реализацию для дальнейшего разъяснения, каково ожидаемое поведение.
P.S.
Насколько я понимаю вот причина, которую Вы хотите, чтобы тест привел к сбою прежде, чем заставить его передать:
Причина, которую Вы "пишете тесту, который Вы знаете, перестанет работать, но протестирует его прежде, чем сделать, передать" случается так, что время от времени, исходное предположение, что тест, конечно, перестанет работать, является неправильным. В тех случаях тест теперь сохранил Вас от написания ненужного кода.
Как другие сказали, молитва TDD не является "никаким новым кодом без провального модульного теста". Я никогда не слышал, что любые практики TDD не говорят "новых тестов, не пропуская код". Новые тесты всегда приветствуются, даже если они, "оказывается", "случайно" передают. Нет никакой потребности изменить Ваш код, чтобы повредиться, затем возвратить его, чтобы пройти тест.
Но что, если Ваш код уже составляет ситуацию, Вы хотите протестировать?
Это повреждает молитву TDD всегда записи проваливающих тестов?
Да, потому что Вы уже повредили молитву записи теста перед кодом. Вы могли просто удалить код и запуститься или просто принять тест, работающий от запуска.
Я много раз сталкивался с этой ситуацией. Пока я рекомендую и пытаюсь использовать TDD, иногда он повреждает поток слишком много для остановки и тесты записи.
У меня есть двухступенчатое решение:
- После того как Вы имеете свой рабочий код и свой непровальный тест, сознательно вставляете изменение в код, чтобы заставить тест перестать работать.
- Сокращение, которые изменяются из Вашего исходного кода и помещают его в комментарий - или в методе кода или в методе тестирования, в поэтому следующий раз, когда кто-то хочет быть уверенным, тест все еще берет отказы, которые они знают, что сделать. Это также служит Вашим доказательством того, что Вы подтвердили, что тест берет отказ. Если это является самым чистым, оставьте его в методе кода. Вы могли бы даже хотеть взять это, насколько использовать условную компиляцию, чтобы включить тестовым прерывателям.