Совсем коротко. Про Assert'ы

Покажусь "снобом и ментором", но напишу:

Возьмите себе за правило - "никаких пустых begin/end".

Если "хотим написать пустой begin/end", то напишите:

begin 
 Assert(false, 'Пока не реализовано'); 
end;

И "наблюдайте за кодом" - когда Assert "всплывёт".

Ну и - О ТЗ, цейтноте и "позабывании"

Ну и пару слов из переписки:

XXX: Если Вы написали функцию которая ничего не делает, то так и напишите "ничего не делать", Ищу цитату из программиста прагматика, добавить в комментарий.

Александр: а лучше написать Assert, если она "не просто ничего не делает", а "мы не знаем - что она должна делать".

Особенно это касается методов интерфейсов, которые "пока непонятно как реализовывать".

Хуже нету "пустых методов" интерфейсов. А вот метод с Assert - "сам за себя говорит".

Ну и "из классиков":

"Подсказка 33
Если что-либо не может произойти, воспользуйтесь
утверждениями, которые гарантируют, что это не произойдет
вовсе"

Ну и "не по теме", но "вдогонку":

"Подсказка 4

Не живите с разбитыми окнами

Не оставляйте "разбитые окна" (неудачные конструкции, неверные решения или
некачественный текст программы) без внимания. Как только их обнаружите, чините
сразу. Если нет времени на надлежащий ремонт, забейте окно досками. Наверняка вы
сможете закомментировать ошибочный фрагмент или вывести на экран сообщение
"В стадии разработки", или использовать фиктивные данные. Необходимо предпри­
нять хотя бы малейшее действие, чтобы предотвратить дальнейшее разрушение, и по­

казать, что вы контролируете ситуацию."

Assert'ы - это как раз "способ диагностировать" те самые "разбитые окна".

Ну и:

Я уже писал - нельзя писать так:

Assert(Supports(X, Y, X));

, а нужно:

if not Supports(X, Y, Z) then 
 Assert(false);

Т.е. не надо "пытаться съэкономить" пустой begin/end.

Ну и всецело подход описан тут:

Ссылка. Пишем простой интерпретатор на C++ с помощью TDD
Тестируем калькулятор №6.2.1. Применяем "классическое TDD"