Как убедиться, что в этом сценарии остались правильные тесты?

Question

Я не знаю, как кратко объяснить мою ситуацию, поэтому мне придется описать сценарий.

У меня есть процесс А, который принимает входной X и выдает выходной сигнал Y. У меня есть отдельный процесс B, который принимает входной сигнал Y (от процесса A), и выдает выходной сигнал Z.

Оба процесса А и B являются сложными и поэтому выиграют от модульного тестирования. Также вероятно, что процессы A и B изменятся, и, таким образом, изменится «средний» формат Y.

Если у меня просто есть модульные тесты для B, которые имеют вход Y, как я могу гарантировать, что они остаются релевантными и правильными, если изменяется процесс A? Например, процесс А превращает вход «foo» в «bar». Тесты единиц для B имеют «бар» в качестве их входных данных и преобразуют их в «переполнение». Если процесс A изменяется и теперь превращается в «foo» в «fish», тогда мои юнит-тесты для B по-прежнему будут проходить, но их ценность сомнительна, поскольку они больше не тестируют ожидаемый ввод.

Что такое наилучшая практика для разрешения этой ситуации? Имеет ли эта ситуация название?

Также (чтобы добавить сложность) процесс B является Java, но процесс A - это Visual Basic.

Я знаю, что переход «за пределы» Единичное тестирование и выполнение тестирования интеграции будет способом гарантировать, что вход X может стать выходным Z, но поскольку у нас есть много тестов для процесса B, как мы можем обеспечить их сохранение Соответствующий? (а также это непросто, когда один из них является Visual Basic, а другой - Java).

Answer 1

Я думаю, что вы уже знаете ответ: интеграция (сквозное) тестирование. Если настройка этого параметра невозможна, лучше всего провести тест X/Y и Y/Z отдельно и убедиться, что всякий раз, когда происходит разрывы (из-за изменений кода), вы обновляете другой, чтобы сохранить данные теста.

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

Answer 2

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

1. Протестируйте взаимодействие

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

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

2. Accept Летучие входные данные

   Альтернатива для вашей второй программы, чтобы принять как можно больше входов, насколько это возможно, и правильно обращаться с ними. Вы может единица измерения это. Процесс проектирования B должен быть максимально отказоустойчивым и писать тесты на столько случаев сбоев, которые вы можете надеяться обработать. Если он должен обрабатывать foo и превратить его в bar, что он должен делать примерно FoO? Или f o o? Как он должен реагировать, если он вообще не получает вход? Такой тип отказоустойчивости является типом loose coupling.

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

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

Answer 3

Если вы не готовы принять интеграционные тесты, то мерой стоп-сигнала будет использование модульных тестов, управляемых данными. Есть много способов сделать эту работу; тот, который ударил меня, когда я прочитал вопрос был:

1. использовать отдельные файлы тест входных и тест проверки для каждого процесса, а затем
2. использовать файл тест проверки для процесса А в качестве тестового входного файла для процесс B

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