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

Question

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

Когда вы вносите изменения, вам нужно запустить оба теста: правильно ли API-интерфейс? И вызывает ли эта последовательность вызовов API изображение, которое выглядит правильно?

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

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

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

Answer 4

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

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