TDD с диаграммами

Question

У меня есть приложение, которое рисует диаграмму. Диаграмма следует определенной схеме,

например, форма X входит в форму Y, формы {X, Y} принадлежат группе P ...

Диаграмма может стать большой и сложной (подумайте о принципиальной схеме).

Каков хороший подход для написания модульных тестов для этого приложения?

Answer 1

1. Узнайте, где сложность в вашем коде.
2. отделите его от непроверенного визуального представления
3. проверить это

Если у вас нет невизуальной сложности, вы не пишете программу, вы создаете произведение искусства.

Если вы не используете ужасно глючный компилятор или что-то подобное, я бы избегал любых тестов, которые сводятся к тому, что «тестовый исходный код делает то, что говорит». Любой тест, который функционально эквивалентен:

assertEquals (hash(stripComments(loadSourceCode())), 0x87364fg3234);

можно удалить без потерь.

Answer 2

Трудно написать определенные модульные тесты для чего-то вроде этого, если вы действительно не понимаете точную последовательность вызовов API, которые будут построены.

Чтобы проверить что-то «визуальное», подобное этому, у вас есть три части.

1. "Шип", чтобы получить правильный внешний вид, масштабирование, цвета и все такое. В некоторых случаях это почти все приложение.

2. «Ручной» тест, который создает некоторые окончательные изображения, чтобы убедиться, что они выглядят правильно для чьего-либо глаза. Нет простого способа проверить это, кроме как посмотреть на фактический результат. Это сложно автоматизировать.

3. Смоделируйте графические компоненты, чтобы убедиться, что ваше приложение вызывает графические компоненты правильно.

При внесении изменений необходимо выполнить оба теста: все ли вызовы API верны? и создает ли эта последовательность вызовов API изображение, которое выглядит правильно?

Вы можете - если вы действительно хотите разорвать мозговую клетку - попытаться создать файл PNG из вашей графики и проверить, правильно ли выглядит файл PNG. Это вряд ли стоит усилий.

По мере продвижения вперед ваши требования могут измениться. В этом случае вам, возможно, придется сначала переписать спайк, чтобы все выглядело правильно. Затем вы можете извлечь последовательность вызовов API для создания автоматических модульных тестов из всплеска.

Можно утверждать, что создание шипа нарушает TDD. Тем не менее, шип предназначен для создания тестируемого графического модуля. Вы не можете легко написать тестовые случаи в первую очередь, потому что процедура теста «показать это человеку». Это не может быть автоматизировано.

Answer 3

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

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

Answer 4

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