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

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

по теме, похоже, нечего сказать?

Я достаточно высказался по теме в предыдущих комментариях.

Ваше намеренное игнорирование проблематики? Да, доказано.

понятней станет откуда у «адйжайл» ноги растут

Они растут совсем не из XP. XP только частный специфический случай Agile. Сами по себе принципы типа «не затыкаться на водопаде» были сформулированы ещё Бруксом, а обязательность тестов выросла ещё из самых правил военной приёмки, от людей, которые не верили ничему, кроме того, что сами видели.

Это то что было у многих на уме — светлая голова Кента Бека выразила словами, простыми принципами.

Ну да, а Apple придумала оконный интерфейс, планшеты, и вообще компьютеры.</mode="kidding">

Учите первоисточники, а не шумных эпигонов.

Это Вам не тут.

Я не силён в теории этих понятий, но если оно 1) постоянно само пускает тесты, 2) умеет прогонять через тесты новые коммиты, то это то, что я имел в виду.

Лучший формат времени для общего применения на сейчас, как ни странно, — NT time.
А за идею использовать unixtime для широкого диапазона дат уже надо начинать ругать.

(Что никак не относится к time_t, %username%)

Подробнее я писал, например, тут: netch80.livejournal.com/17832.html

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

Сколько времени — определяется по возможностям — но это не менее 20%, а в соседних ветках рекомендовали 50%. Этого должно гарантированно хватить на доведение до рабочего состояния. Ну и см. выше про архитектуру.

Чем он отличается от других средств continuous integration?

Так не бывает. У разных схем и задач распределения практически нет ничего общего, кроме самого факта выполнения чего-то не на одном процессоре.

Хехе, не зря я убил из почты предложение работы от некоей Marina Kopytova. Может, компания и приличная, но пока в ней такие сотрудники — её стоит обходить за километр.

P.S. Не рассказывайте сказки, что ничего не посылали:)

Ну и пусть себе хотят дальше:)

Вот на тему глубокого дебага — как раз проверка выполнения контракта является нормальной там, где разработчики или слишком ленивы, чтобы сидеть в отладчике (привет Луговскому), или не в состоянии, например, потому что софт выполняется на далёком сервере и обрабатывает в реалтайме сотни параллельных сущностей (как на моих работах). Реализуется это уже способом, специфичным для языка, платформы и обстановки: где-то это просто assert, где-то вывод в лог, где-то увеличение счётчика... главное, чтобы проблема была известна и опознавалась (хотя бы до такого уровня, чтобы в следующей версии плавно углубиться в неё). Фактически, я отладчик как инструмент не запускал на своих задачах уже... мнэээ... лет 10:) Вижу его только у дочки на задачах по информатике (когда задача тривиальна, но требуется понять, что именно нужно).

К ссылке про контракты в Аде — оно очень похоже выглядит в Erlang. Например, если функция foo должна получать на входе список, достаточно записать её определение в виде

...

вместо простого

...

и рантайм автоматически проверит (точнее, он будет искать подходящее определение, но для foo(X) с X не списком он его не найдёт и будет исключение типа function_clause).

Подозреваю наличие аналогичных средств в других ФЯ, но не видел.

Схожие средства я применял в случае особо тяжело понимаемого кода, например, если я знаю, что функция должна вернуть record(nns), пишу

NewNNS = #nns{} = process_message(Message, OldNNS)

и в рантайме выполняется соответствующая проверка.

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

Это я чуть пробежался по теме «мысью по древу», она значительно обширнее, но описал практически важные «в среднем по больнице» вехи. Главное — не бойтесь форсировать в коде проверку выполнения условия конкретного контракта, по крайней мере в отладочных сборках; это поможет не только отладке, но и чтению.

> И, кстати, эйчары не набирают людей на работу.

На практике они существенно влияют на набор людей на работу, и, насколько я вижу, в основном не лучшим образом.

А что эти две? Как приколы у них песни отличные, развеять голову от засушенного кода:)

Никакой Си не даст результат, что "5"-3==2, но "5"+3=="53″. И точно так же никакой Си со своим синтаксисом не даст того, что если после слова return перевести строку, то выражение за ним проигнорируется в ноль. Это всё PHP’шные выбредки.

... и от необходимости трезво, связно и чётко излагать мысли.

Ключевое слово — «разумная». Хотя кому-то и APL слишком многословен.