Если Вы изменяете код, который имеет модульный тест против него, который Вы изменяете сначала?

Если вы следуете методам TDD , вам следует сначала обновить свои тесты. У вас будут неработающие тестовые примеры, которые, надеюсь, будут исправлены, когда вы исправите код.

Лучше сначала обновить тесты и дать им потерпеть неудачу, а затем вернуться и обновить код до тех пор, пока тест не пройдет успешно. AKA Разработка через тестирование или Разработка через тестирование.

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

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

EDIT (в ответ на комментарий): Я предпочитаю сначала написать тест, но это стиль TDD. В таком случае дизайн тест-драйвов. Также существует ритм и закономерность такого рода разработки (рефакторинг красный-зеленый). Наоборот, это более простой способ модульного тестирования: вы уже разработали и реализовали то, что хотите, теперь вы это тестируете. В этом нет ничего плохого, это другой подход к разработке, и выбор не зависит от наличия других тестов. Это действительно подход к развитию в целом.

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

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

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

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

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