Приложение базы данных поблочного тестирования с бизнес-логикой, выполненной в UI
Я управляю довольно крупным приложением (50k + строки кода) один, и оно справляется с некоторыми довольно критическими бизнес-действиями. Для описания простой программы я сказал бы, что это - необычный UI со способностью отобразить и изменить данные из базы данных, и это управляет приблизительно 1 000 рентных единиц, и о 3k арендаторах и всех финансах.
Когда я вношу изменения, потому что это является настолько большим из кодовой базы, я иногда повреждаю что-то где-то в другом месте. Я обычно тестирую его путем движения, хотя материал, который я изменил на функциональном уровне (т.е. Я запускаю программу и работу через UI), но я не могу протестировать на каждую ситуацию. Именно поэтому я хочу начать с поблочным тестированием.
Однако это не истинное, три программы уровня с уровнем базы данных, бизнес-уровнем и уровнем UI. Большая бизнес-логика выполняется в классах UI, и много вещей сделаны на событиях. Для усложнения вещей все - база данных, управляемая, и я не видел (до сих пор) хороших предложений о том, как взаимодействиям базы данных модульного теста.
Как был бы хороший путь для начала работы с поблочным тестированием на это приложение. Иметь в виду. Я никогда не делал поблочного тестирования или TDD прежде. Я должен переписать его для удаления бизнес-логики из классов UI (большая работа)? Или есть ли лучший путь?
11 ответов
Я бы начал с использования некоторого инструмента, который тестировал бы приложение через пользовательский интерфейс. Существует ряд инструментов, которые можно использовать для создания тестовых сценариев, имитирующих щелчок пользователя по приложению.
Я бы также посоветовал вам начинать добавлять модульные тесты по мере добавления новых функций. Создание полного покрытия после разработки приложения занимает много времени, но если вы делаете это постепенно, вы распределяете усилия.
Мы тестируем взаимодействие с базой данных, имея отдельную базу данных, которая используется только для модульных тестов. Таким образом, у нас есть статический и управляемый набор данных, поэтому запросы и ответы могут быть гарантированы. Затем мы создаем код C # для моделирования различных сценариев. Для этого мы используем nUnit.
TDD подразумевает, что вы создаете (и запускаете) модульные тесты по мере продвижения. Для того, что вы пытаетесь сделать - добавлять модульные тесты постфактум - вы можете подумать об использовании чего-то вроде Typemock (коммерческий продукт). Кроме того, вы, возможно, создали систему, которая не поддается модульному тестированию, и в этом случае может потребоваться некоторый (или большой) рефакторинг.
Рефакторинг - лучший способ. Несмотря на то, что процесс сложный, вам определенно следует разделить презентацию и бизнес-логику. Вы не сможете писать хорошие модульные тесты против вашей бизнес-логики, пока не сделаете это разделение. Это так просто.
В процессе рефакторинга вы, вероятно, обнаружите ошибки, о существовании которых даже не подозревали, и, в конце концов, станете гораздо лучшим программистом!
Кроме того, после рефакторинга кода вы заметите, что тестирование взаимодействия с базой данных станет намного проще. Вы сможете писать тесты, которые будут выполнять такие действия, как «добавить нового клиента», которые будут включать создание фиктивного объекта-клиента и сохранение «его» в базу данных. Для следующего теста вы должны написать «GetTenant» и попытаться получить этот клиент, который вы только что создали из базы данных, в свое представление в памяти ... Затем сравните свой первый и второй клиент, чтобы убедиться, что все поля соответствуют значениям. И т. Д. И т. Д.
Я не пробовал добавлять тесты для устаревших приложений, так как это действительно сложная задача. Если вы планируете переместить часть бизнес-логики из пользовательского интерфейса на отдельный уровень, вы можете добавить сюда свои начальные тестовые единицы (рефакторинг и TDD). Это даст вам представление о создании модульного теста для вашей системы. Это действительно большая работа, но я думаю, это лучшее место для начала. Поскольку это приложение, управляемое базой данных, я предлагаю вам использовать некоторые имитирующие инструменты и инструменты DBunit при создании теста для имитации проблем, связанных с базой данных.
Я настоятельно рекомендую прочитать статью Эффективная работа с устаревшим кодом . Он описывает работоспособную стратегию того, чего вы пытаетесь достичь.
Я бы порекомендовал взять книгу Майкла Фезерса Эффективная работа с устаревшим кодом . Это покажет вам множество техник для постепенного увеличения тестового покрытия в вашей кодовой базе (и попутно улучшая дизайн).
Я думаю, что всегда полезно отделить бизнес-логику от пользовательского интерфейса. У этого есть несколько преимуществ, включая более легкое модульное тестирование и расширяемость. Вы также можете обратиться к программированию на основе шаблонов. Вот ссылка http://en.wikipedia.org/wiki/Design_pattern_ (computer_science) , которая поможет вам понять шаблоны проектирования.
На данный момент вы могли бы сделать одно: в классах пользовательского интерфейса изолировать всю бизнес-логику и различные функции бизнес-баз, а в каждом конструкторе пользовательского интерфейса или page_load иметь вызовы модульного теста, которые проверяют каждую из бизнес-функций. Для удобства чтения вы можете применить тег #region к бизнес-функциям.
Для получения долгосрочной выгоды вам следует изучить шаблоны проектирования. Выберите шаблон, который соответствует потребностям вашего проекта, и повторите проект, используя этот шаблон.
Это зависит от того, какой язык вы используете. Но в целом начните с простого класса тестирования, который использует некоторые выдуманные данные (но все же что-то «реальное») для тестирования вашего кода. Сделайте имитацию того, что произойдет в приложении. Если вы вносите изменения в определенную часть приложения, напишите что-нибудь, что работает, прежде чем изменять код. Теперь, поскольку вы уже написали код, тестирование будет довольно сложной задачей при попытке протестировать все приложение. Я бы посоветовал начать с малого. Но теперь, когда вы пишете код, сначала напишите модульное тестирование, а затем напишите свой код. Вы также можете подумать о рефакторинге, но я бы немного взвесил затраты на рефакторинг и переписывание, когда вы будете проводить модульное тестирование на этом пути.
Во-первых, я бы порекомендовал прочитать хорошую книгу о модульном тестировании, например Искусство модульного тестирования . В вашем случае уже немного поздно выполнять разработку через тестирование вашего существующего кода, но если вы хотите написать свои модульные тесты на его основе, то вот что я бы порекомендовал:
- Изолируйте код, который вы хотите протестировать, в библиотеки кода. (если их еще нет в библиотеках).
- Запишите наиболее распространенные сценарии использования и преобразуйте их в приложение, использующее ваши библиотеки кода.
- Убедитесь, что ваша тестовая программа работает так, как вы от нее ожидаете.
- Преобразуйте вашу тестовую программу в модульные тесты, используя среду тестирования.
- Получите зеленый свет. Если нет, то ваши модульные тесты неисправны (при условии, что ваши библиотеки кода работают), и вам следует выполнить некоторую отладку.
- Увеличьте охват кода и сценария ваших модульных тестов: Что делать, если вы ввели неожиданные результаты?
- Получите зеленый свет снова. Если модульный тест не прошел, вероятно, ваша библиотека кода не поддерживает расширенное покрытие сценария, поэтому пришло время рефакторинга!
А для нового кода я бы посоветовал вам попробовать его с помощью Test Driven Development.
Удачи (оно вам понадобится!)
Нет лучшего способа начать модульное тестирование, чем попробовать его - это не займет много времени, это весело и увлекательно. Но только если вы работаете над тестируемым кодом .
Однако, если вы попытаетесь изучить модульное тестирование, исправив сразу все приложение, подобное тому, которое вы описали, вы, вероятно, разочаруетесь и расстроитесь - и, скорее всего, вы просто подумаете, что модульное тестирование - это пустая трата времени.
Я рекомендую загрузить фреймворк для модульного тестирования, например NUnit или XUnit.Net . У большинства этих фреймворков есть онлайн-документация с кратким введением, например Быстрый запуск NUnit . Прочтите это, а затем выберите простой автономный класс, который:
- Имеет мало или совсем не зависит от других классов - по крайней мере, не от сложных классов.
- Имеет определенное поведение: простой контейнер с кучей свойств мало что покажет вам о модульном тестировании.
Попробуйте написать несколько тестов, чтобы получить хорошее покрытие для этого класса, затем скомпилируйте и запустите тесты.
Как только вы это освоите, начните искать возможности для рефакторинга существующего кода , особенно при добавлении новых функций или исправлении ошибок. Когда эти рефакторинги приводят к классам, отвечающим указанным выше критериям, напишите для них несколько тестов. Когда вы привыкнете к , вы можете запустить , написав тесты .
Один из вариантов - каждый раз, когда возникает ошибка, напишите тест, который поможет вам найти ошибку и решить проблему. Сделайте так, чтобы тест прошел, когда ошибка будет исправлена. Затем, как только ошибка будет устранена, у вас будет инструмент, который поможет вам обнаружить будущие изменения, которые могут повлиять на кусок кода, который вы только что исправили. Со временем охват тестированием улучшится, и вы сможете запускать постоянно растущий набор тестов в любое время, когда вносите потенциально далеко идущие изменения.