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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Ответ 5

Во-первых, я бы рекомендовал прочитать хорошую книгу об модульном тестировании, например The Art Of Unit Testing. В вашем случае немного поздно выполнить Test Driven Development на вашем существующем коде, но если вы хотите написать свои юнит-тесты вокруг него, то вот что я бы рекомендовал:

• Изолируйте код, который вы хотите протестировать, в библиотеки кода (если они еще не находятся в библиотеках).
• Выпишите наиболее распространенные сценарии использования сценария и переведите их в приложение, использующее ваши библиотеки кода.
• Убедитесь, что ваша тестовая программа работает так, как вы ожидаете.
• Преобразуйте свою тестовую программу в модульные тесты с использованием структуры тестирования.
• Получите зеленый свет. Если нет, то тесты вашего устройства ошибочны (при условии, что ваши библиотеки кода работают), и вы должны выполнить некоторую отладку.
• Увеличьте охват кода и сценария ваших модульных тестов: что делать, если вы ввели неожиданные результаты?
• Получите зеленый свет снова. Если unit test терпит неудачу, возможно, что ваша библиотека кода не поддерживает расширенный охват сценария, поэтому время рефакторинга!

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

Удачи (вам нужно это!)

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

Я думаю, что всегда хорошая идея отделить вашу бизнес-логику от пользовательского интерфейса. Там есть несколько преимуществ, включая более легкое тестирование и расширяемость модулей. Вы также можете обратиться к программированию на основе шаблонов. Вот ссылка http://en.wikipedia.org/wiki/Design_pattern_(computer_science), которая поможет вам понять шаблоны проектирования.

Одна вещь, которую вы могли бы сделать сейчас, находится в ваших классах пользовательского интерфейса, изолировать всю бизнес-логику и различные функции бизнес-баз, а не внутри каждого конструктора пользовательского интерфейса или page_load есть вызовы unit test, которые проверяют каждую из бизнес-функций. Для улучшения читаемости вы можете применить тег #region вокруг бизнес-функций.

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

Ответ 9

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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