Если вы тестировали функцию count, подобную приведенной ниже, считается ли она «правильной» или «неправильной» для проверки нескольких вещей для функции в одной функции и наличия тестовой функции для каждого из тестов?
function testGetKeywordCount() { $tester = $this -> getDatabaseTester($this -> CompleteDataFile); $tester -> onSetUp(); $KeywordID = 0; $this -> setExpectedException('InvalidArgumentException'); $this -> keyword -> getKeywordCount($KeywordID,'Active'); $KeywordID = 1; $this -> setExpectedException('InvalidArgumentException'); $this -> keyword -> getKeywordCount($KeywordID,'InvalidStatus'); $this -> assertEquals(1, $this -> keyword -> getKeywordCount($KeywordID,'Active')); $tester -> onTearDown(); } У вас должно быть несколько тестовых функций, где каждый проверяет свое собственное состояние. Таким образом легче обнаружить отказ без отладки.
Наличие одного теста для каждого сценария является идеальным. Тем не менее, в некоторых случаях это более удобно (эффективно с точки зрения усилий внедрения) для тестирования более одного сценария в одном тестовом случае. Если вы используете фреймворк, который не останавливается при первом сбое, но пытается выполнить как можно больше в тестовом примере, эта структура подходит для нескольких сценариев на каждый тестовый пример.
Я предпочитаю проводить как можно меньше времени на модульном тестировании и по-прежнему получать как можно больше информации за это время.
В конце концов, это не так, как вы выполняете единичный тест, но больше правильность этих тестов.
Структуры тестирования не всегда делают все возможное, чтобы следовать одному утверждению за правило тестирования.
Один из них – RSpec для Ruby, который позволяет вам создавать вложенные группы примеров . Например:
Постепенно создавая сценарии и проверяя каждый шаг на этом пути, его легче придерживаться одного утверждения на каждый тестовый подход. Это также облегчает определение непроверенных сценариев.
Один аргумент для разделения утверждений на два отдельных теста состоит в том, что, если одно из утверждений терпит неудачу, вы получите один сбой; если оба утверждения потерпят неудачу, вы получите два отказа.
Кроме того, сделав имя каждого теста максимально возможным, вы получите дополнительные подсказки, когда что-то сломается.
Я бы не говорил об модульных тестах в приведенном выше примере кода.
Ваш пример – более автоматизированный функциональный тест, который проверяет поток функций.
НО В этом случае прекрасно иметь несколько утверждений.
Просто убедитесь, что 2 утверждения не одно за другим.
Плохой пример
public void ValidateRulesEntry_Valid_ValidConditionsFromFile() { string condition = "Target.HasValue"; string returnMessage; bool successFul = CodeParserTryParseCondition(condition, out returnMessage); Assert.IsTrue(successFul); Assert.IsFalse(string.IsNullOrEmpty(returnMessage)); Assert.IsTrue(returnMessage == "OK"); }
2 последних утверждения зависят от 1-го утверждения IsTrue (successFul).
Подумайте: если этот тест не удастся -> Скажите мне, почему (не глядя на вывод Debug)
Это вопрос с разными ответами в зависимости от того, кого вы спрашиваете, и в основном зависит от его личного мнения или профессионального опыта. Некоторые ультра теоретические люди скажут вам, что наличие более одного утверждения в тесте является высшим грехом, и вы обречены навсегда. Но другие, обладающие более реальным опытом в мире, могут сказать вам, что есть ситуации, когда неплохо иметь 10 или даже 50 утверждений за тест.
Итак, кто прав?
Я всегда стараюсь быть объективным, когда сталкиваюсь с такими дилеммами, и, чтобы сделать выбор, я решил провести небольшое исследование с некоторыми из самых популярных репозиторий github, которые разрабатываются сегодня сертифицированными и опытными специалистами.
Итак, как крупные игроки тестируют свои собственные проекты? И что более важно, как сами модульные модули тестирования тестируются самостоятельно?
Давайте рассмотрим несколько примеров:
зимовать
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/test/java/org/hibernate/engine/spi/EntityEntryTest.java https://github.com/hibernate/hibernate -orm / blob / master / hibernate-core / src / test / java / org / hibernate / engine / spi / NonSortedExecutableListTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/ src / test / java / org / hibernate / engine / spi / SortedExecutableListTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-envers/src/test/java/org/hibernate/envers /test/JpaStaticMetamodelTest.java https://github.com/hibernate/hibernate-orm/blob/master/hibernate-hikaricp/src/test/java/org/hibernate/test/hikaricp/HikariCPConnectionProviderTest.java https: // github .com / спящий режим / спящий режим-ОРМ / блоб / ведущий / спящий режим-proxool / SRC / тест / Java / орг / спящий режим / тест / proxool / ProxoolConnectionProviderTest.java
весна
https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/AntPathMatcherTests.java https://github.com/spring-projects /spring-framework/blob/master/spring-core/src/test/java/org/springframework/util/ClassUtilsTests.java https://github.com/spring-projects/spring-framework/blob/master/spring- core / src / test / java / org / springframework / util / ObjectUtilsTests.java https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/test/java/org/springframework /util/AutoPopulatingListTests.java
junit 4
https://github.com/junit-team/junit4/blob/master/src/test/java/junit/tests/extensions/ActiveTestTest.java https://github.com/junit-team/junit4/blob/master /src/test/java/junit/tests/extensions/RepeatedTestTest.java https://github.com/junit-team/junit4/blob/master/src/test/java/junit/tests/runner/ResultTest.java https : //github.com/junit-team/junit4/blob/master/src/test/java/org/junit/rules/TimeoutRuleTest.java
junit 5
https://github.com/junit-team/junit5/blob/master/platform-tests/src/test/java/org/junit/platform/launcher/core/DefaultLauncherTests.java https://github.com/junit -team / junit5 / blob / master / platform-tests / src / test / java / org / junit / platform / launcher / core / LauncherDiscoveryRequestBuilderTests.java https://github.com/junit-team/junit5/blob/master/ platform-tests / src / test / java / org / junit / platform / launcher / listener / SummaryGenerationTests.java https://github.com/junit-team/junit5/blob/master/junit-jupiter-engine/src/test /java/org/junit/jupiter/engine/StandardTestClassTests.java https://github.com/junit-team/junit5/blob/master/junit-jupiter-engine/src/test/java/org/junit/jupiter/ двигатель / DiscoveryFilterApplierTests.java
Google Truth
https://github.com/google/truth/blob/master/core/src/test/java/com/google/common/truth/DoubleSubjectTest.java https://github.com/google/truth/blob/master /core/src/test/java/com/google/common/truth/BigDecimalSubjectTest.java https://github.com/google/truth/blob/master/core/src/test/java/com/google/common/ истина / DoubleSubjectTest.java
Как мы видим в приведенных выше примерах, профессиональные разработчики, похоже, не очень заботятся о единой команде assert. Фактически, они нарушают это правило большую часть времени, и похоже, что с ним все в порядке. Возможно, они игнорируют это, потому что это не строгое правило, а рекомендация. Стоит отметить, что даже модульные модули тестирования тестируют себя чаще, чем несколько утверждений на тест большую часть времени.
Таким образом, мой вывод ясен: в отношении этой проблемы вполне справедливо иметь столько утверждений, сколько вы хотите в одном тесте. Если профессиональные разработчики это делают, вы тоже можете это сделать.