Как отдельный трекер раньше использовали TrackStudio. По возможностям Redmine и рядом не валялся. Но по интерфейсу та версия TrackStudio была довольно замороченной. В конце концов решает интеграция — отдельный трекер неудобен.
После обсуждения с коллегами идея формулируется так:
Автоматическая привязка тестов к коду. Для теста задается условие (шаблон или как там в АОП, поинткат?), при выполнении которого устанавливаются значения некоторых переменных и происходит запуск теста (переменные могут в тесте использоваться). Если при этом не хватает какого-то кода привязки, который не может быть сгенерирован — тест не проходит.
Если методы create для T и С не найдены — тест не проходит.
Пример 2: для каждого интерфейса ${I} и класса ${C}, который его реализует, надо выполнить заданный тест:
void test( ${I} i ) {
…
}
с параметром create${C}
методы create на самом деле могут быть итераторами, то есть возвращать набор значений, а использовать надо все комбинации.
наверное, возможностей create хватит не всегда, надо еще какой-то механизм придумать
И это только одна из проблем, согласен. Не судите строго, идея пришла мне в голову после прочтения статьи, надо ещё обдумать. Есть вроде инструмент, которые автоматически генерируют код, создающий объект заданного типа.
Спасибо за интересную мысль. Мысль рассматривать тесты как навесные проверки для своего кода мне почему-то в голову не приходила. Возможно, потому что тесты — штука очень конкретная. Если дополнить непрерывный прогон тестов генерацией этих самых тестов по определенным правилам, будет интереснее. Поясню свою мысль — есть у нас интерфейс. Написали тесты, которые проверяют его семантику. Я хочу, чтобы эти тесты выполнялись для каждой реализаии интерфейса, появляющейся в проекте. Без лишних телодвижений со стороны разработчикОВ.
itunes>Психологический метод обеспечивает точность в 89.6%
?
и почему не 90? какая погрешность измерений? :)
Как отдельный трекер раньше использовали TrackStudio. По возможностям Redmine и рядом не валялся. Но по интерфейсу та версия TrackStudio была довольно замороченной. В конце концов решает интеграция — отдельный трекер неудобен.
Evernote — для запомнить навсегда
+ расширения для интеграции с Firefox
Всё как Вы хотите — с возможностью скачать на локальный диск и с синхронизацией, в том числе с андроидом.
C помощью какого мехнизма тесты перестают проходить при появлении нового контроллера?
При появлении нового контроллера ваши тесты перестают проходить?
Автоматическая привязка тестов к коду. Для теста задается условие (шаблон или как там в АОП, поинткат?), при выполнении которого устанавливаются значения некоторых переменных и происходит запуск теста (переменные могут в тесте использоваться). Если при этом не хватает какого-то кода привязки, который не может быть сгенерирован — тест не проходит.
Пример 1: шаблон такой: для каждого метода с именем $© get${F}() в классе ${T}, если существует метод set${F}( ${C} ), выполняем такой тест:
${T} t = create${T}();
${C} f = create${C}();
t.set${F}( f );
assertTrue( t.get${F}() == f );
Если методы create для T и С не найдены — тест не проходит.
Пример 2: для каждого интерфейса ${I} и класса ${C}, который его реализует, надо выполнить заданный тест:
void test( ${I} i ) {
…
}
с параметром create${C}
методы create на самом деле могут быть итераторами, то есть возвращать набор значений, а использовать надо все комбинации.
наверное, возможностей create хватит не всегда, надо еще какой-то механизм придумать