Покрытие графов в тестировании ПО, часть 2

[amarao]

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

Прочитал. Осталось ощущение, что случайно найденная страница из книги.

Где практика-то? ОК, молодцы, какие-то фрагменты теории графов. А как это к реальной жизни-то относится?

[svidersky]

Поддерживаю комментарий. Давайте в третьей части сделаем примеры из вашей практики с применением этих знаний :)

[Renius]

Теория графов нужна для взвешивания тестирования, все ли пути и ребра покрыты тестами или все ли кейсы покрыты тестами. Первое TDD, второе BDD. Мне так кажется.
В предидущей статье автор писал что он не программист, а тестировщик.

К реальной жизни это относится очень просто:
def calculate(a, b, operator)
…
Практика: в реальной жизни научится раскладывать такую функцию в граф для эффективного тестирования
[validate args, calculate sum, result]
[validate args, calculate diff, result]
[validate args, calculate div, result]
[validate args, calculate div by zero, result]

Я думаю понимание придет с практикой почти сразу

[LaoAx]

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

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