Тестирование приемо-сдаточных испытаний?

Question

В настоящее время я принимаю некоторые Приемочные тесты, которые помогут управлять дизайном программы, которую я собираюсь сделать. Все кажется прекрасным, за исключением того, что я понял, что Acceptance-Tests являются довольно сложными, то есть, хотя они концептуально просты, для них требуется довольно сложный код. Мне нужно сделать несколько «вспомогательных» классов для моих приемочных тестов.

Мой вопрос заключается в том, как развивать их:

1. Сделать Юнит-тесты моих приемо-тестов (это кажется странным, - кто-нибудь сделал что-нибудь, как это?)
2. сделать блок-тесты для эти классы помощи. После того, как я выполнил весь код этих классов помощи, я могу пройти и начать работать над настоящими модульными тестами моей системы. При использовании этого подхода, где бы вы поместили вспомогательные классы? В проекте тестов или в реальном проекте? Они не обязательно имеют зависимости от тестирования/издевательств.
3. Любая другая идея?

Answer 1

Если вы думаете о разработке программного обеспечения, как о заводе по производству автомобилей, тогда акт написания программного обеспечения похож на разработку нового автомобиля. Каждый компонент тестируется отдельно, потому что он новый. Это никогда не делалось раньше. (Если у вас есть, вы можете либо получить людей, которые сделали это раньше, либо купить их с полки.)

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

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

Answer 2

Нет ничего плохого в использовании модульной тестовой среды (например, JUnit) для написания приемочных испытаний (или интеграционных тестов). Люди не любят называть их «модульными тестами» по многим причинам. Для меня основная причина заключается в том, что тесты интеграции/приёма не будут выполняться каждый раз, когда кто-то проверяет изменения (слишком длинный или/или без надлежащей среды).

Ваши вспомогательные классы - это стандартная вещь, которая содержит «код инфраструктуры инфраструктуры». Они не принадлежат нигде, кроме тестового кода. Это ваш выбор, чтобы проверить их или нет. Но без них ваши тесты не будут осуществимы в больших системах.

Итак, ваш выбор № 2 или никаких тестов тестов вообще. Нет ничего плохого в реорганизации кода инфраструктуры, чтобы сделать его более прозрачным и простым.

Answer 3

Ваш вариант 2 - это то, как я это сделаю: сначала введите классы-помощники - похоже, вы знаете, что они должны делать.

Тесты - это тесты, и хотя классы-помощники не являются строго критериями, на них не будет ссылаться ваш основной код, просто тесты, поэтому они принадлежат к тестам. Возможно, они могут находиться в отдельном пакете/пространстве имен из регулярных тестов.

Answer 4

Друг очень заинтересован в том, что приемочные испытания говорят вам, что ваш код сломан, в то время как модульные тесты сообщают вам , где он сломан; это дополнительные и ценные фрагменты информации. Приемочные тесты лучше дают вам знать, когда вы закончите.

Но для того, чтобы сделать все, вам понадобятся все части по пути; вам нужно, чтобы они работали, и это то, что на модульных тестах отлично. Сделанные тесты - во-первых, они также приведут вас к лучшему дизайну (а не только к коду, который работает). Хороший подход - написать приемочное испытание с большой картинкой и сказать себе: «Когда это проходит, я закончил». Затем проделайте работу, чтобы пройти, работая в TDD: напишите небольшой блок-тест для следующего небольшого количества функций, необходимых для прохождения AT-прохода; напишите код, чтобы он прошел; рефакторинга; повторение. По мере того, как вы прогрессируете, время от времени выполняйте AT; вы, вероятно, обнаружите, что это не удается позже и позже в тесте. И, как упоминалось выше, когда он проходит, вы закончили.

Я не думаю, что модульное тестирование приемочного испытания само по себе имеет смысл. Но подразделение, проверяющее свои классы-помощники - действительно, написание этих тестов - это очень хороший способ. Скорее всего, вы найдете некоторые методы, которые вы пишете «только для теста», работая в производственном коде, и даже если вы этого не сделаете, вы все равно хотите знать, что код, используемый вашим AT, работает правильно.

Если ваш AT достаточно прост, старая пословица «тест проверяет код и код проверки теста», вероятно, достаточен - когда у вас есть неудачный тест, это либо из-за неправильного кода, либо из-за того, что тест неправильный, и это должно быть достаточно легко выяснить, какой. Но когда тест сложный, хорошо также хорошо проверять его основы.