TDD для компиляторов

IRL на работе от тебя требуют «джвести фич к вечеру прикрутить», а тесты... ну не будет их - и ладно, лишь бы джвести фич было. Наверняка те энтузиасты, которым хватает сил вечером еще и компиляторы пилить, уже слишком деформированы RL чтобы делать «правильно»

А конкретно, какие именно? gcc использует, вроде. По крайне тест-сьют у него вроде был. И еще, он бутстрапится (причем в 3 шага) — сойдет за тесты?

Mono тоже имеет test suite. И пых тоже. И sbcl вроде. Это из того, что приходилось тыкать в последнее время.

А так можно было бы точно знать, какие фичи уже поддерживаются, какие нет, на сколько процентов компилятор соответствует стандарту.

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

Есть стандарт, который почти формальным языком описывает конструкции языка и поведение скомпилированного кода. Перевести это в юнит-тест - такая трудная задача?

Это не юнит-тест.

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

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

Компиляторы относятся к классу самоверифицирующихся программ. Если компилятор не прошёл «теста» на собственную компиляцию из нескольких поколений, то такой компилятор не для релиза.

Почему почти никакие (распространённые, тем более) компиляторы не используют модульные тесты или вообще TDD при разработке? Удалось нагуглить только поделки студентов. Гуру программирования не умеют в современные средства разработки?

Может, просто «гуру программирования» могут написать 20 строк корректного кода, не написав под него 100 строк юнит-тестов? Ну а студенты, соответственно, не могут. В результате первые продумывают алгоритм и, если нужно, покрывают тестами, а вторые обязательно пишут несколько тестов, а потом набор костылей и подпорок, который хоть как-то проходит их.

И вообще, софт сегодня - слишком динамично развивающаяся область, и писать на каждую строку кода 5 строк тестов - это добровольно сокращать свою производительность в шесть раз. При том, что через полгода весь код будет, возможно, выкинут на свалку вместе с тестами и заменён новым.

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

З.Ы. Сам являюсь веб-разработчиком, где 90% кода - это интеграция с внешними сервисами (отправить HTTP-запрос, распарсить ответ) или реализация прокладки между пользователем и сервером БД, и для написания юнит-тестов придётся мОчить половину реальной системы, так что тесты просто нерентабельны.

Ты, видимо, даже не понял, что такое TDD.

Почему почти никакие (распространённые, тем более) компиляторы не используют модульные тесты или вообще TDD при разработке?

а зачем? есть ведь CL, есть пайтон, есть php наконец! Если ты накручиваешь говнокод из говна и палок по принципу «лишь бы работало» (TDD по-русски), то накручивай. При чём тут компиляторы? В C/C++ этот подход работает плохо, можешь их за это ненавидеть.

Ты, видимо, даже не понял, что такое TDD.

И что же это?

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

Однако грамотное построение тестов требует столько же, если не больше, времени, как и написание кода. Немногие готовы за это платить. Для среднестатистического заказчика проще заплатить за ТЗ, написанное быстро и на относительно понятном ему языке, и потом вручную пару раз пройтись по заложенному функционалу, чтоб убедиться, что всё работает. Потому что когда внезапно обнаружится, что получилось не то что он хотел и надо будет всё переделать, это можно будет сделать _быстро_.

Я пытался в каком-то виде применить это для своих проектов, но не получалось. Когда в системе 500 тестов и ты добавляешь функцию, предварительно написав для неё 5-10 тестов, удобно видеть, что ничто не сломалось. Однако, на написание тех 500 тестов уходит столько времени и рефакторинга, что в моём случае выигрыша это не давало.

Можешь продемонстрировать _выгоду_ от TDD на конкретном примере? Статьи в интернете, которые показывают, как удобно можно покрыть тестами встроенную в язык операцию сложения, увеличив время разработки всего в 5-10 раз, не считаются.

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

Это правильно. Но в предыдущем твоём посте было не об этом, а о модульных тестах вообще.

Однако грамотное построение тестов требует столько же, если не больше, времени, как и написание кода.

Однако грамотное проектирование требует столько же, если не больше, времени, как и написание кода.

Как это можно вообще сравнивать?

Я пытался в каком-то виде применить это для своих проектов, но не получалось.

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

Однако, на написание тех 500 тестов уходит столько времени и рефакторинга, что в моём случае выигрыша это не давало.

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

Можешь продемонстрировать _выгоду_ от TDD на конкретном примере? Статьи в интернете, которые показывают, как удобно можно покрыть тестами встроенную в язык операцию сложения, увеличив время разработки всего в 5-10 раз, не считаются.

«Приведи пример, только не приводи примера.» Как ты себе это представляешь?

Можешь продемонстрировать _выгоду_ от TDD на конкретном примере? Статьи в интернете, которые показывают, как удобно можно покрыть тестами встроенную в язык операцию сложения, увеличив время разработки всего в 5-10 раз, не считаются.

Kent Beck - Test-Driven Development by Example