Модульное тестирование приложения базы данных с бизнес-логикой, выполненной в пользовательском интерфейсе

Question

Я сам управляю довольно большим приложением (50 000+ строк кода), и оно управляет некоторыми довольно важными бизнес-действиями. Чтобы описать простую программу, я бы сказал, что это модный пользовательский интерфейс с возможностью отображения и изменения данных из базы данных, и он управляет около 1000 единиц аренды, а также около 3 тысяч арендаторов и всеми финансами.

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

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

Как было бы хорошим способом начать модульное тестирование для этого приложения. Иметь ввиду. Я никогда не делал модульное тестирование или TDD раньше. Должен ли я переписать его, чтобы удалить бизнес-логику из классов пользовательского интерфейса (много работы)? Или есть лучший способ?

Answer 1

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

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

Мы тестируем взаимодействие с базой данных, имея отдельную базу данных, которая используется только для модульных тестов. Таким образом, у нас есть статический и управляемый набор данных, так что запросы и ответы могут быть гарантированы. Затем мы создаем код на C # для имитации различных сценариев. Для этого мы используем nUnit.

Answer 2

Я настоятельно рекомендую прочитать статью Эффективная работа с устаревшим кодом .В нем описывается работоспособная стратегия для того, чего вы пытаетесь достичь.

Answer 3

TDD подразумевает, что вы создаете (и запускаете) модульные тесты по ходу работы. Для того, что вы пытаетесь сделать - добавьте модульные тесты после факта - вы можете рассмотреть возможность использования чего-то вроде Typemock (коммерческий продукт). Кроме того, вы, возможно, создали систему, которая не подходит для модульного тестирования, и в этом случае может потребоваться некоторый (или много) рефакторинг.

Answer 4

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

Answer 5

Я бы порекомендовал взять книгу Майкла Фезерса Эффективная работа с устаревшим кодом . Это покажет вам много методов для постепенного увеличения покрытия тестами в вашей кодовой базе (и улучшения дизайна на этом пути).

Answer 6

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

1. Изолируйте код, который вы хотите протестировать, в библиотеки кода (если их еще нет в библиотеках).
2. Напишите наиболее распространенные сценарии сценариев использования и переведите их в приложение, использующее ваши библиотеки кода.
3. Убедитесь, что ваша тестовая программа работает так, как вы ожидаете.
4. Преобразование вашей тестовой программы в модульные тесты с использованием инфраструктуры тестирования.
5. Получите зеленый свет. Если нет, то ваши модульные тесты неисправны (при условии, что ваши библиотеки кода работают), и вы должны выполнить некоторую отладку.
6. Расширить охват кода и сценариев ваших юнит-тестов: что делать, если вы ввели неожиданные результаты?
7. Получите зеленый свет снова. Если модульный тест не пройден, то, вероятно, ваша библиотека кода не поддерживает расширенное покрытие сценария, поэтому время рефакторинга!

А для нового кода я бы предложил вам попробовать его с помощью Test Driven Development.

Удачи (она вам понадобится!)

Answer 7

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

В процессе рефакторинга вы, скорее всего, найдете ошибки, о которых вы даже не подозревали, и, в конце концов, станете намного лучшим программистом!

Кроме того, как только вы выполните рефакторинг своего кода, вы заметите, что тестирование ваших взаимодействий с БД станет намного проще. Вы сможете написать тесты, которые выполняют такие действия, как: «добавить нового арендатора», что включает создание фиктивного объекта арендатора и сохранение «его» в БД. Для следующего теста вы должны написать «GetTenant» и попытаться получить тот арендатор, который вы только что создали из базы данных, в свое представление в памяти ... Затем сравните свой первый и второй арендатор, чтобы убедиться, что все поля соответствуют значениям. И т. Д.

Answer 8

Я не пробовал добавлять тест для устаревших приложений, так как это действительно сложная работа. Если вы планируете перенести часть бизнес-логики из пользовательского интерфейса и на отдельный уровень, вы можете добавить свои начальные тестовые единицы здесь (рефакторинг и TDD). Это даст вам представление о создании модульного теста для вашей системы. Это действительно много работы, но я думаю, это лучшее место для начала. Поскольку это приложение, управляемое базой данных, я предлагаю вам при создании теста использовать некоторые инструменты для насмешек и DBunit, чтобы имитировать проблемы, связанные с базой данных.

Answer 9

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

Однако, если вы попытаетесь научиться модульному тестированию, исправив приложение, подобное тому, которое вы описали сразу, вы, вероятно, расстроитесь и будете разочарованы - и есть хороший шанс, что вы просто подумаете, что модульное тестирование - это трата времени.

Я рекомендую загрузить платформу для модульного тестирования, такую ​​как NUnit или XUnit.Net . Большинство из этих платформ имеют интерактивную документацию, которая содержит краткое введение, например, NUnit Quick Start . Прочитайте это, затем выберите простой, автономный класс, который:

• Имеет мало или совсем не зависит от других классов - по крайней мере, не от сложных классов.
• Имеет некоторое поведение: простой контейнер с кучей свойств не особо покажет вам о модульном тестировании.

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

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

Answer 10

Это зависит от языка, который вы используете. Но в целом начните с простого класса тестирования, который использует некоторые готовые данные (но все же что-то «реальное») для тестирования вашего кода. Заставьте его симулировать, что произойдет в приложении. Если вы вносите изменения в определенную часть приложения, напишите что-нибудь, что работает, прежде чем менять код. Теперь, так как вы уже написали код, тестирование будет довольно сложной задачей при попытке протестировать все приложение. Я бы предложил начать с малого. Но теперь, когда вы пишете код, сначала напишите модульное тестирование, а затем - свой код. Вы могли бы также подумать о рефакторинге, но я бы взвесил затраты на рефакторинг по сравнению с переписыванием, когда вы пройдете модульное тестирование.