Как найти шаблоны (строки, круги, …) из списка точек?

TDD стал любимым подходом разработчиков программного обеспечения, которые серьезно относятся к своей профессии. [ IEEE: TDD ] Преимущества этого подхода значительны, а затраты по сравнению с ним невелики. [ Три закона TDD ]

Нет программных доменов, для которых TDD не подходит или неэффективен. Однако есть домены, в которых это сложно. Игры, оказывается, один из них.

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

Теперь, прежде чем все будут реветь и говорить: «Дядя Боб говорит:« Не делай TDD для UI »», позвольте мне сказать это. Тот факт, что трудно сделать чистый TDD для пользовательского интерфейса, не означает, что вы не можете сделать чистый TDD почти для всего остального. Большая часть игр связана с алгоритмом, и вы можете использовать TDD с этими алгоритмами на свое усмотрение. Это правда, особенно в играх, что некоторые из этих алгоритмов - это тот код, с которым вам нужно работать, как и в пользовательском интерфейсе, и поэтому они, вероятно, не поддаются тестированию вначале . Но есть много другого алгоритмического кода, который можно и нужно сначала написать для проверки.

Хитрость заключается в том, чтобы следовать принципу единой ответственности (SRP) и отделить те виды кода, с которыми вам придется поиграться, от тех видов, которые являются детерминированными. Не используйте в своем интерфейсе простые для тестирования алгоритмы. Не смешивайте ваш спекулятивный код с вашим не спекулятивным кодом. Храните вещи, которые меняются по причине А, отдельно от вещей, которые меняются по причине Б .

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

Проблема с написанием тестов «по факту» состоит в том, что часто код настолько связан, что трудно писать виды хирургических тестов, которые являются наиболее полезными. Поэтому, если вы пишете код, который сначала сложно протестировать , , вам следует соблюдать принцип инверсии зависимостей (DIP) и открывать / закрывать принцип (OCP) для того, чтобы код оставался достаточно разъединенным для проверки после факта.