тдд с нетривиальными алгоритмами

Question

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

Как я могу использовать метод tdd в такой ситуации?

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

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

Спасибо за вашу помощь.

Answer 1

Вы правы, что TDD - это тестирование интерфейсов, а не реализация. Тем не менее, почему вы хотите проверить фактическую реализацию? Дело в том, что если вы достаточно протестируете интерфейс, реализация не имеет значения .

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

Answer 2

Если ваша реализация сложна, то было бы неплохо разбить ее на более мелкие модули. Эти меньшие модули будут иметь собственный интерфейс, который вы будете тестировать. Например, если вы решаете судоку, выполняя поиск в глубину, то стоит отдельно разработать алгоритм поиска в глубину и алгоритм подсчета положения в судоку. Я писал об этом некоторое время назад: http://matteo.vaccari.name/blog/archives/416

Answer 3

Я нашел пример TDD / BDD в книге RSpec очень полезным - http://www.pragprog.com/titles/achbd/the-rspec-book это может быть кое-что, на что ориентируется рельсы, но в книге автор переходит от определения проблемы к идентификации простых тестовых случаев к сложным случаи в интуитивной манере. Пример в этой книге о разработке игры и ее продвижении к прохождению всех тестов.

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

Answer 4

Чтобы проверить, содержит ли реализация некоторые ограничения (например, количество сравнений, производительность и т. Д.), Вы можете изменить эти ограничения с помощью тестов.

Я нашел этот разговор в Твиттере очень проницательным: http://twitoaster.com/kentbeck/brunopedroso-i-think-you-could-tdd-quicksort-youd-need-assertions-about-the-of-comparisons-ways-to-incrementally-improve-the-count/

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

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

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

Answer 5

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

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