Как подойти к реализации интерфейса TDD

Question

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

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

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

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

Я ошибаюсь? Или я слишком многого ожидаю?

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

Answer 1

Шаг 1. Что должен сделать интерфейс ? Одна вещь.

Шаг 2. Как вы докажете, что это делает одно?

Шаг 3. Напишите тест, чтобы доказать, что интерфейс действительно это делает.

Шаг 4. Запустите тест - он не пройдёт. Вы на самом деле не написали интерфейс.

Шаг 5. Код интерфейса.

Шаг 6. Тест пройдёт.

Переходите к следующему пункту, который интерфейс должен сделать.

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

Answer 2

Я хочу добавить некоторые функциональные возможности по сравнению с базовым доступом к файловой системе, чтобы FUSE выглядел вполне подходящим

Трудно разработать плавкий предохранитель fs.Две основные проблемы - ОЧЕНЬ сложная отладка и многопоточность.Также у меня были (и сейчас есть) проблемы с тестированием моего фс.Возможно inotify удовлетворит ваши требования.

Answer 3

Даже если он ориентирован только на Ruby, Книга rspec содержит хорошее введение в цикл BDD.