Я полагаю, вам придется создать путь для каждого соединения. Например, в визуале вы должны переместить соединение на 5 пикселей вправо, затем на 10 вниз, затем сдвинуть вправо, пока вы не достигнете центра целевого узла, а затем двигаться вверх.
Создание этих правил не было бы слишком плохо, если бы вы установили вертикальные и горизонтальные поля для узлов.
Как насчет использования 1-го раздела примера с деньгами Кента Бека . Все начинается очень просто, но когда вы прибавляете к добавлению двух разных валют, TDD внезапно показывает вам ложность первоначального дизайна, или YAGNI (вам это не понадобится).
Другой хороший пример - дядя Боб Пример TDD для боулинга . Я думаю, что это хороший пример того, как описательная часть TDD приводит вас к чистому решению, которое было бы явно недоступным через предварительный дизайн.
Чтобы сделать это действительно захватывающей презентацией, заранее Вы могли бы предложить аудитории спроектировать два сценария, используя любые методы, которые они сочтут подходящими. Затем вы покажете TDD способ их разработки.
Настоящий момент WTF для меня с TDD был, когда Бек удалил два подкласса Money, и тесты сработали. Это не тривиальное действие; Человек удалил два класса! Уверенность в том, чтобы сделать что-то подобное, может быть найдена только двумя способами.
1) сбор всех старших игроков в кодовой базе и проработка сценариев с последующим обширным завершением, чтобы подтвердить его работоспособность
2) TDD
= D
If you have time for it, I would pick an example with an external dependency of some sort that is going to get abstracted in the test. Either a database, calls to a GUI, calls to a remote system, etc.
The reason is that one of the blocks to TDD is that the example seems too self contained. "Sure, when everything is a self-contained unit you can unit test, but when I have 15 systems to integrate, what is the point?" kind of thing.
I would also at least show one example at the end (look at Michael Feather's book Working Effectively with Legacy Code for how-tos) of migrating an existing class to bring it under TDD. Don't dwell on that as an example, but odds are your audience will be thinking about how to migrate the class they wrote that morning, no reason to let that fester as an "unmentionable."
TDD problems has a list of problems, ranging from simple to less simple.
Some have a list of tests to start from no solution yet.
Нет, числа с плавающей запятой могут автоматически повышаться до двойных, но удвоения никогда не могут быть числами с плавающей запятой без явного приведения, потому что у двойников больший диапазон.
диапазон значений с плавающей запятой 1.40129846432481707e-45
- 3.40282346638528860e + 38
двойной диапазон - это 4.94065645841246544e-324d
- 1.79769313486231570e + 308d
Кроме того, я посетил презентацию TDD несколько лет назад, где примером был простой калькулятор, и он прекрасно работал.
Три мне нравятся, в порядке возрастания сложности:
Если бы у меня было полчаса, я бы сделал Range; 90 минут, вероятно, Натуральная сортировка; больше: Змея. Хотя зависит от аудитории.
Я бы попытался найти что-то маленькое в известной области. Недавно я выступил с докладом о BDD / TDD на основе ASPNET.MVC. Это включало один контроллер, одно действие и модель представления. Это также дало мне возможность представить контейнер зависимостей и среду для насмешек.
Как насчет простого математического класса с сложением, вычитанием, умножением и тому подобным?
Другим классическим примером из сообщества TDD / Extreme / Agile является пример игры в боулинг; Кажется, я вспоминаю, что он использовался как Беком, так и Мартином, а также несколько раз на xprogramming.com для примеров и исследований различных методов в TDD.
Выйти на конечность и принимать запросы от аудитории. :)
Если целью является продажа TDD, вы также хотите показать небольшой рефакторинг большой тестовой базы. Его легко заставить работать с небольшими образцами, большинство разработчиков сейчас в него вкладывают. Гораздо больше сомнений в масштабируемости. Тогда передовой темой будет вопрос о том, как обрабатывать большую базу унаследованного кода (без юнит-тестов).
Было бы неплохо сыграть в простую карточную игру, тем более что вы можете предоставить некоторое визуальное представление о результате
И я полагаю, вы Вы собираетесь использовать додзё кодирования в качестве формы презентации? Нет фантазии PowerPoint. Если публика не программисты, используйте образец Excel
Я бы посоветовал вам купить книгу Тестовый дизайн на примере от Кента Бека.
Книга почти полностью посвящена построению одного класса с помощью TDD.
римские цифры. Количество строк без комментариев исходного кода. Башни Ханоя. Там много идей.