Это может быть не полный по Тьюрингу формализм, но 99% также будут хороши:).
Извините, но я бы предпочел предоставить NP-полное решение:)
Быстрый ответ от меня будет Подход, основанный на тестировании . Но читайте дальше, чтобы узнать больше.
Проблема, как я понимаю, в том, что мы должны
представьте много сценариев на одном
объект, который намного сложнее, чем
следствие независимых операций.
В таких случаях очень полезна декомпозиция (не только в смысле информатики , но и в математическом ).
Вы разбиваете сложный сценарий на множество более простых , которые, в свою очередь, сами по себе могут быть сложными и могут быть разложены далее.
В результате такого процесса вы должны получить ряд простых функций (задач), в основном независимых от каждой из них.
Это очень важно, потому что тогда вы можете UNIT TEST в этих простых сценариях.
Кроме того, гораздо проще и лучше следовать подходу вначале теста , который позволяет увидеть декомпозицию в самом начале процесса разработки.
Используете ли вы математические формализмы и подходы к управлению состоянием сложных объектов?
Продолжая то, что я сказал, для меня самое главное - сделать хорошее разложение, чтобы я мог гарантировать качество и возможность легко воспроизводить ошибки в автоматическом режиме.
Чтобы дать вам абстрактный пример :
У вас есть сложный сценарий A. Вам всегда нужно написать не менее 3 тестов для каждого сценария: правильный ввод, неправильный ввод и угловой регистр (ы).
Начиная писать первый тест (правильный ввод) Я понимаю, что тест становится слишком сложным .
В результате я разлагаю сценарий A на менее сложные A1, A2, A3. Затем я снова начинаю писать тесты для каждого из них (у меня должно быть не менее 3 * 3 = 9 тестов).
Я понимаю, что A1 все еще слишком сложен для тестирования, поэтому я снова разлагаю его на A1-1, A1-2. Теперь у меня есть 4 различных сценария (A1-2, A1-2, A2, A3) и 3 * 4 = 12 потенциальных тестов. Я продолжаю писать тесты.
После того, как я закончу. Я начинаю реализацию , поэтому все мои тесты пройдены. После этого у вас есть 12 доказательств того, что сценарий A (точнее его части) работает правильно . Кроме того, вы можете написать еще 3 теста для сценария A, который объединяет все его разложенные части - этот вид тестирования часто (но не всегда!) Можно рассматривать как интеграционное тестирование .
Тогда давайте предположим, что в сценарии A найдена ошибка. Вы не уверены, к какой части он принадлежит, но подозреваете, что он связан с A1-2 или A3. Таким образом, вы пишете еще 2 теста для каждого сценария, чтобы воспроизвести ошибку (напишите такой тест, который не соответствует вашим ожиданиям). После того, как вы воспроизвели ошибку, вы исправляете ее и выполняете ВСЕ тесты.
Теперь у вас есть еще 2 доказательства правильной работы системы, обеспечивающей одинаковую работу всех предыдущих функций.
У этого подхода есть две основные проблемы.
- Вам нужно написать множество тестов и поддержать их. Многие разработчики просто не хотят, чтобы делал это.
- Кроме того, процесс разложения - это больше искусство, чем наука. Хорошая декомпозиция приведет к хорошей структуре, тестам и поддержке, а плохая - к большому количеству боли и потраченному времени. И трудно сказать, является ли разложение хорошим или плохим вначале.
Этот процесс называется Test-Driven-Development . Я считаю, что это ближайшая «формализация» процесса разработки, которая хорошо сочетается между наукой и реальным миром .
Так что я на самом деле говорю не о состоянии, а о поведении и доказательстве того, что оно работает правильно.
Из личного опыта я должен отметить, что ASP.NET WebForm технически ОЧЕНЬ сложно тестировать.
Чтобы преодолеть это, я бы предложил применить шаблон MVP для ASP.NET WebForms .
В отличие от WebForms, ASP.NET MVC намного проще для тестирования.
Но, тем не менее, вы должны иметь набор так называемых «сервисов» (наши сценарии) и (модульно) тестировать их отдельно, а затем тестировать интеграцию пользовательского интерфейса в среде, близкой к тестам интеграции.