Активировать несколько условий в одном тесте или разбить на несколько тестов?

Question

Если вы тестировали функцию подсчета, подобную приведенной ниже, считается ли она «правильной» или «неправильной» для проверки нескольких вещей для функции в одной функции и наличия тестовой функции для каждого из тестов?

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(); 
} 

Answer 1

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

Answer 2

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

Я предпочитаю проводить как можно меньше времени на модульном тестировании и по-прежнему получать как можно больше освещения за это время.

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

Answer 3

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

Один, который делает это RSpec для Ruby, что позволяет вам установить nested example groups. Например:

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

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

Answer 4

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

BUT В этом случае хорошо иметь несколько утверждений.

Просто убедитесь, что 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 (аукционная).

Подумайте о следующем: Если тест не пройден -> Скажите мне, почему (не смотря на выход отладки)

Answer 5

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

Кроме того, сделав имя каждого теста максимально возможным, вы получите дополнительные подсказки, когда что-то сломается.

Answer 6

Это вопрос с различными ответами в зависимости от того, кого вы спрашиваете, и в основном зависит от его личного мнения или профессионального опыта. Некоторые ультра теоретические люди скажут вам, что наличие более одного утверждения в тесте является высшим грехом, и вы обречены навсегда. Но другие, обладающие более реальным опытом в мире, могут сказать вам, что есть ситуации, когда неплохо иметь 10 или даже 50 утверждений за тест.

Итак, кто прав?

Я всегда стараюсь быть объективным, когда сталкиваюсь с такими дилеммами, и, чтобы сделать выбор, я решил провести небольшое исследование с некоторыми из самых популярных репозиториев github, которые сегодня разрабатываются сертифицированными и опытными специалистами.

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

Давайте посмотрим несколько примеров:

Hibernate

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/hibernate/hibernate-orm/blob/master/hibernate-proxool/src/test/java/org/hibernate/test/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/engine/DiscoveryFilterApplierTests.java

Google Правда

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/truth/DoubleSubjectTest.java

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

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