Дык кто этим занимается: вы сами, или поддержка есть в системе CI, которую вы используете? В любом случае, это не решает проблему с кодом, который использует транзакции (он работает некорректно, тесты не проходят).
Я расплывчатый ответ попробую конвертировать в конкретный: если в ветке удалили таблицу, остальные разработчики останавливают работу (модульные тесты не работают) и ждут, пока ветка уйдет в транк. Потом они обязаны (иначе тесты не будут проходить) каждый в свою ветку влить новый транк. При этом если процесс мерджа у первого разработчика затянулся, все остальные сидят и курят. Я ничего не напутал?
А в чем конкретно проблема тестирования фичи в ветке? Сделал фичу, прогнал тесты. Если все ок, влил в ветку транк, опять прогнал тесты. В случае наличия конфликтов решаются они все в ветке.
Если делать старт транзакции в setup, а откат в teardown, то наличие транзакций в тестируемом коде приведет к неприятным последствиям. По крайней мере в mysql, где старт новой транзакции влечет автоматический коммит предыдущей.
Еще неясно следующие: в ветке удалили таблицу, поправили тесты и перед мерджем их запустили. Как в это время гонять тесты в других ветках, которым все еще нужна таблица?
Уточнил у ребят — действительно все так, это я напутал. Так что насчет невозможности был не прав, теоретически это возможно. Но интересно, как это работает, если в самом проекте используются транзакции?
По секрету расскажу вам идеальную схему удаленной работы. Есть сервер разработки, на нем крутиться web и 1 инстанс бд
Это вполне помещается на ноут. Повторюсь: если в системе есть хотя бы какие-то тесты (модульные, функциональные), описанная выше схема работать не будет, о чем я жирно намекнул в соседней ветке комментариев.
Вообще-то хорошем тоном является наличие у каждого разработчика своего тестового окружения, в котором может полноценно крутиться разрабатываемая система. И нормальные разработчики перед каждым коммитом гоняют как минимум модульные, а как максимум и функциональные тесты.
Несколько лет практикуем точно такую же систему, вполне удобно.
Раньше использовали простеньний мигратор, который позволял: применить все не примененные миграции, от последней примененной до указной и просто все. Потом научили его обрабатывать патчи (в нашем случае это код на перле). Патчи бывают полезны, когда необходимо произвести сложные манипуляции с данными в бд и возможностей sql недостаточно. Они подчиняются тем же правилам что и обычные миграции, только хендлер другой.
Кстати, подход раш + допиливание хорошо работает и в больших проектах. Причем стадия активной разработки может длиться 2-3 недели. Дольше сложно т.к. это сильно истощает команду. Плюс нужно быть готовым к тому, что велосити последующих итераций может оказаться существенно ниже обычной.
Единственное, я бы не стал жертвовать качеством — это обычно не окупается даже в среднесрочной перспективе.
Лучше для функционального тестирования использовать специализированные инструменты, мне кажется, например, selenium или selenium rc. Хотя, функциональные тесты на, например, XML-API мы тоже пишем на xUnit.
Я вообще имел в виду, что для написания функциональных тестов использовать xUnit не самое разумное решение и есть специализированные инструменты. Все остальное ниже за меня написали :)
Стандартный юзкейз: есть класс, хочешь посмотреть как он работает — ищешь тест, читаешь. В случае с несколькими файлами это сделать гораздо сложнее, как мне кажется.
И, повторюсь, в случае небольших классов (а они должны быть небольшими, иначе — выделение класса) необходимость дробить тесты отпадает сама собой. Более 200 строк — это большой класс, больше 500 — огромный. Плюс не стоит забывать о том, что тестирование — это далеко не основная задача TDD и слишком тщательное тестирование — плохой запах.
Все вышесказанное относится к модульному тестированию.
AAA — интересная концепция. Думаю, многие интуитивно стараются ей следовать, но если возвести ее в ранг правила при написании тестов, читабельность существенно увеличится.
Что касается нескольких тестовых классов (и файлов) на один класс модели. Мне кажется это неправильным нескольким причинам:
1. Неудобно искать тест для конкретного класса.
2. Неудобно использоваться тест как документацию (приходится бегать между классами).
3. Самое главное: если класс модели большой и требует большого теста, самое время подумать о рефакторинге «выделение класса».
Я расплывчатый ответ попробую конвертировать в конкретный: если в ветке удалили таблицу, остальные разработчики останавливают работу (модульные тесты не работают) и ждут, пока ветка уйдет в транк. Потом они обязаны (иначе тесты не будут проходить) каждый в свою ветку влить новый транк. При этом если процесс мерджа у первого разработчика затянулся, все остальные сидят и курят. Я ничего не напутал?
Еще неясно следующие: в ветке удалили таблицу, поправили тесты и перед мерджем их запустили. Как в это время гонять тесты в других ветках, которым все еще нужна таблица?
Это вполне помещается на ноут. Повторюсь: если в системе есть хотя бы какие-то тесты (модульные, функциональные), описанная выше схема работать не будет, о чем я жирно намекнул в соседней ветке комментариев.
Раньше использовали простеньний мигратор, который позволял: применить все не примененные миграции, от последней примененной до указной и просто все. Потом научили его обрабатывать патчи (в нашем случае это код на перле). Патчи бывают полезны, когда необходимо произвести сложные манипуляции с данными в бд и возможностей sql недостаточно. Они подчиняются тем же правилам что и обычные миграции, только хендлер другой.
Единственное, я бы не стал жертвовать качеством — это обычно не окупается даже в среднесрочной перспективе.
И, повторюсь, в случае небольших классов (а они должны быть небольшими, иначе — выделение класса) необходимость дробить тесты отпадает сама собой. Более 200 строк — это большой класс, больше 500 — огромный. Плюс не стоит забывать о том, что тестирование — это далеко не основная задача TDD и слишком тщательное тестирование — плохой запах.
Все вышесказанное относится к модульному тестированию.
Что касается нескольких тестовых классов (и файлов) на один класс модели. Мне кажется это неправильным нескольким причинам:
1. Неудобно искать тест для конкретного класса.
2. Неудобно использоваться тест как документацию (приходится бегать между классами).
3. Самое главное: если класс модели большой и требует большого теста, самое время подумать о рефакторинге «выделение класса».
В целом, полезная публикация, спасибо.