если у меня есть метод, который вызывает другой метод, какой бы простой он не звучал, это юнит-тест или интеграционный тест?
К сожалению, это будет зависеть от того, чейопределение используемых вами «модульного теста» и «интеграционного теста».Двадцать лет назад, когда эти определения определялись экспертами в области тестирования программного обеспечения, на этот вопрос было бы легче ответить.
Но TDD случился;и Кент Бек не был особенно дисциплинирован в своих определениях, и начали появляться новые идеи.
Даже в контексте TDD существуют тонкие разногласия по поводу того, что означает «модульный тест».Например, одна важная идея заключается в том, что тесты не должны быть чувствительны к порядку их выполнения;Каждый отдельный тест содержал все настройки и демонтаж, необходимые для правильного измерения системы.Другое состояло в том, что два теста, выполняющиеся одновременно в одном и том же процессе, не должны мешать друг другу;поэтому нет общего изменяемого состояния ..
Общей темой здесь является то, что test ограничен;«модульный тест» будет описывать тесты, которые имеют определенный набор свойств.
Другая идея возникла из наблюдения, что большие тесты, без очень тщательного проектирования, являются хрупкими в течение всего жизненного цикла проекта.Если наблюдаемое поведение испытуемого , в свою очередь, зависит от множества различных решений, которые могут измениться, то хрупкие испытания являются распространенным результатом.
Таким образом, возникло иное ограничение, предполагая, что испытуемые должны быть маленькими - «модульный тест» - это тот, в котором поведение испытуемого зависит только от небольшого числа решений, которые могут потенциально измениться..
Добавляя еще больше путаницы к миксу, ритуалы, которые Бек и другие использовали с некоторым успехом, продавались в разное время как «Test First Development», «Test Driven Development», «Test Driven Design» -- что смутило мотивацию.Является ли цель test или design?
Как я могу сказать, все согласны с тем, что метод, который не делегирует какую-либо свою работу, является хорошим предметом для модульного теста.
Кроме того, все согласны с тем, что метод, который делегирует свою работу стабильным сотрудникам (например, стандартной библиотеке), является хорошим предметом для модульного теста.
Но разногласия начинаются, когда мы заменяемдизайн, который не использует соавторов, с дизайном, который использует нестабильных соавторов (делегирование работы другим методам, особенно если они находятся в разных «классах»).
Будет ли это все еще модульным тестом, если мы изменим дизайн, чтобы разделить работу между нестабильными частями?Я вполне уверен, что Бек скажет «да», как и Фриман и Прайс.Я менее уверен насчет @JBrains;см. Интегрированные тесты - афера .Некоторые провели свои собственные эксперименты и пришли к выводу, что находят для них работы;другие интерпретируют «лучшие практики», описанные их любимыми экспертами.
Короче: это беспорядок.
Лучший ответ, который я могу предложить, - это вместо того, чтобы беспокоиться о метки , которые мы используем для различных вариантов тестов, сконцентрируемся на интересных наборах свойств , тех ограничениях, которые необходимы для обеспечения того, чтобы тесты обладали этими свойствами, и согласовании этих свойств с их использованием.
Например, если вы собираетесь запускать тесты много раз во время сеанса разработки, как механизм для раннего обнаружения ошибок, то вы, вероятно, хотите, чтобы эти тесты были быстрыми и независимыми от того, что происходит в средах вне вашей собственной.,Чтобы получить эти свойства, вам, вероятно, нужно избегать сетевого трафика в ваших тестах, и, возможно, даже ввода-вывода - выполнение «всего» в памяти происходит намного быстрее (и оставляет вас подверженным определенным рискам, с которыми вам придется управлять вдругие способы).