TDD, каковы ваши методы поиска хороших тестов?

StackOverflow https://stackoverflow.com/questions/418707

Вопрос

Я пишу простое веб-приложение, используя Linq to Sql в качестве слоя данных, так как мне очень нравится Linq2SQL.В последнее время я немного читал о DDD и TDD и хотел попробовать.

Прежде всего мне бросается в глаза, что Linq2SQL и DDD не слишком хорошо сочетаются.Моя другая проблема заключается в поиске тестов, на самом деле мне очень трудно определить хорошие тесты, поэтому я хотел спросить, каковы ваши наилучшие методы обнаружения хороших тестовых примеров.

Это было полезно?

Решение

Поиск тестовых примеров - это скорее искусство, чем наука.Однако простые рекомендации включают в себя:

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

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

Другие советы

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

Подумай.Прочтите код.Спросите себя:например ,может ли этот указатель никогда не быть нулевым здесь?Что произойдет , если этот метод будет вызван перед инициализацией ?

Не делайте предположений такие , как "этот файл всегда будет там".Тест.

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

Ошибки часто группируются по кластерам.Оглянитесь вокруг, когда найдете его.Также ищите такого же рода ошибки в других местах.

Настройтесь на реальную цель тестирования: поиск ошибок.

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

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

Я регулярно пишу тесты для сторонних API. Таким образом, когда API обновляется, я знаю, сломаюсь или нет.

Не связан с StackOverflow
scroll top