Применение TDD, когда приложение составляет 100% CRUD

Just an idea...

Take the requirements for the CRUD, use tools like watij or watir or AutoIt to create test cases. Start creating the UI to pass the test cases. Once you have the UI up and passing maybe just one test, start writing the logic layer for that test, and then the db layer.

For most users, the UI is the system. Remember to write test cases for each new layer that you are building. So instead of starting from the db to app to ui layer, start in the reverse direction.

At the end of the day, you would probably have a accumulated a powerful set of regression test set, to give you some confidence in doing refactoring safely.

this is just an idea...

Skip it. All will be just fine. I'm sure you have a deadline to meet. (/sarcasm)

Next month, we can go back and optimize the queries based on user feedback. And break things that we didn't know we weren't supposed to break.

If you think the project will last 2 weeks and then never be reopened, automated testing probably is a waste of time. Otherwise, if you have a vested interest in "owning" this code for a few months, and its active, build some tests. Use your judgement as to where the most risk is. Worse, if you plan on being with the company for a few years, and have other teammates who take turns whacking on various pieces of a system, and it may be your turn again a year from now, build some tests.

Don't over do it, but do "stick a few pins in it", so that if things start to "move around", you have some alarms to call attention to things.

Most of my testing has been JUnit or batch "diff" type tests, and a rudimentaryy screen scraper type tool I wrote a few years ago (scripting some regex + wget/curl type stuff). I hear Selenium is supposed to be a good tool for web app UI testing, but have not tried it. Anybody have available tools for local GUI apps???

Мне кажется, мы путаем TDD с модульным тестированием.

Модульное тестирование - это особые тесты, которые проверяют единицы поведения. Эти тесты часто включаются в сборку интеграции. С.Лотт описал некоторых отличных кандидатов именно для этих типов тестов.

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

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

Сейчас я работаю над приложением CRUD. На данный момент я пишу модульные тесты для своих объектов репозитория и проверяю, что функции CRUD работают должным образом. Я обнаружил, что это по своей сути также проверяет фактический код базы данных. Таким образом, мы обнаружили довольно много ошибок в коде базы данных. Поэтому я предлагаю вам продвигаться вперед и продолжать модульные тесты. Я знаю, что применение TDD в приложениях CRUD не так гламурно, как то, о чем вы могли бы прочитать в блогах или журналах.

Я сейчас работаю над чистым приложением CRUD Но я вижу множество преимуществ модульных тестов (примечание - я не сказал TDD)

Я сначала пишу код, а затем , затем тестовые примеры, но никогда не слишком разрозненные, но достаточно скоро

И я тестирую операции CRUD - также сохраняемость для базы данных.

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

Итак, ИМХО, всегда есть преимущества TDD \ Unit-тестирования (как бы вы его ни называли, в зависимости от того, насколько сильно вы к нему относитесь) - даже для приложения CRUD Вам просто нужно найти правильную стратегию для своего приложения

Просто руководствуйтесь здравым смыслом ... и все будет в порядке.

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

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