Как делает разделы модульного теста кода, которые являются процедурными или основанными на событии
Если вам нужно проверить удаленные URL-адреса в поле ввода, вы можете попробовать протестировать простое регулярное выражение с типами, которые вас интересуют.
$input_field = $('.js-input-field-class');
if ( !(/\.(gif|jpg|jpeg|tiff|png)$/i).test( $input_field.val() )) {
$('.error-message').text('This URL is not a valid image type. Please use a url with the known image types gif, jpg, jpeg, tiff or png.');
return false;
}
Это приведет к захвату всего, что заканчивается .gif, .jpg, .jpeg, .tiff или .png
Следует отметить, что некоторые популярные сайты, такие как Twitter, добавляют атрибут размера к концу своих изображений. Например, следующее испытание не удастся выполнить, даже если это допустимый тип изображения:
https://pbs.twimg.com/media/BrTuXT5CUAAtkZM.jpg:large
Из-за этого это не идеальное решение. Но это приведет вас к 90% пути.
7 ответов
Идея поблочного тестирования состоит в том, чтобы протестировать маленькие разделы кода с каждым тестом. В основанной на событии системе, одной форме поблочного тестирования, которое Вы могли сделать, должен будет протестировать, как Ваши обработчики событий отвечают на различные события. Таким образом, Ваш модульный тест мог бы установить аспект Вашей программы в определенное состояние, затем назвать метод прослушивателя событий непосредственно и наконец протестировать последующее состояние Вашей программы.
При планировании на поблочном тестировании основанной на событии системы Вы сделаете свою жизнь намного легче для себя, если Вы будете использовать шаблон внедрения зависимости и идеально пойдете целым путем и инверсией использования управления (см. http://martinfowler.com/articles/injection.html и http://msdn.microsoft.com/en-us/library/aa973811.aspx для деталей этих шаблонов),
(благодаря pc1oad1etter для указания я испортил ссылки),
При ответе на мой собственный вопрос здесь, но я столкнулся со статьей, которые берут, объясняет проблема и делает пошаговую демонстрацию простого примера - Разработка Гибкого пользовательского интерфейса. Код и изображения являются большими, и вот отрывок, который показывает идею:
Гибкие гуру, такие как Kent Beck и David Astels предлагают создать GUI путем сохранения объектов представления очень тонкими, и тестирования слоев "ниже поверхности". Это "умное объектное/тонкое представление" модель походит на знакомое представление документа и парадигмы клиент-сервер, но относится к разработке отдельных элементов GUI. Разделение содержания и презентация улучшают дизайн кода, делая это более модульным и тестируемым. Каждый компонент пользовательского интерфейса реализован как умный объект, содержа поведение приложения, которое должно быть протестировано, но никакой код презентации GUI. Каждый умный объект имеет соответствующий тонкий класс представления, содержащий только универсальное поведение GUI. С этой моделью дизайна здание GUI становится поддающимся TDD.
Сначала я протестировал бы события как это:
private bool fired;
private void HandlesEvent(object sender, EventArgs e)
{
fired = true;
}
public void Test()
{
class.FireEvent += HandlesEvent;
class.PErformEventFiringAction(null, null);
Assert.IsTrue(fired);
}
И Затем я обнаружил RhinoMocks. RhinoMocks является платформой, которая создает фиктивные объекты, и он также обрабатывает тестирование события. Это может пригодиться для Вашего процедурного тестирования также.
Проблема состоит в том, что "основанное на событии программирование" связывает слишком много логики с событиями. Путем такая система должна быть разработана, то, что должна быть подсистема, которая генерирует события (и можно записать тесты, чтобы гарантировать, что эти события генерируются в надлежащем порядке). И должна быть другая подсистема, которая имеет дело только с управлением, скажем, состоянием формы. И можно записать модульный тест, который проверит, что, учитывая корректные исходные данные (т.е. сгенерированные события), установит состояние формы на правильные значения.
Кроме того, обработчик фактических событий, который повышен от 1 компонента и называет поведение на 2 компонента, является просто интеграционным тестированием, которое может быть сделано вручную человеком QA.
Ваш вопрос не указывает Ваш предпочтительный язык программирования, но мой - C#, таким образом, я буду иллюстрировать использование это. Это - однако просто улучшение по ответу Gilligans при помощи анонимных делегатов для встраивания тестового кода. Я полностью поддерживаю тесты создания, максимально читаемые, и мне, который имеет в виду весь тестовый код в методе тестирования;
// Arrange
var car = new Car();
string changedPropertyName = "";
car.PropertyChanged += delegate(object sender, PropertyChangedEventArgs e)
{
if (sender == car)
changedPropertyName = e.PropertyName;
};
// Act
car.Model = "Volvo";
// Assert
Assert.AreEqual("Model", changedPropertyName,
"The notification of a property change was not fired correctly.");
Класс я тестирую здесь реализации INotifyPropertyChanged взаимодействуйте через интерфейс и поэтому a NotifyPropertyChanged событие должно быть сгенерировано каждый раз, когда значение свойства изменилось.
Подход, который я нашел полезными для процессуального кодекса, должен использовать TextTest. Это не так о поблочном тестировании, но это помогает Вам сделать автоматизированное регрессионное тестирование. Идея состоит в том, что у Вас есть свое приложение, пишут, что журнал затем использует texttest для сравнения журнала прежде и после изменений.
Посмотрите, что часто связанный Работает Эффективно с Унаследованным кодом. Посмотрите, что разделы, названные "Мое Приложение, Являются Всеми Вызовами API", и "Мой Проект не Объектно-ориентирован. Как я Вношу Безопасные Изменения?".
В мире C/C++ (мой опыт) лучшее решение на практике состоит в том, чтобы использовать компоновщика "шов", и ссылка против теста удваивается для всех функций, вызванных функцией под тестом. Тем путем Вы не изменяете ни одного унаследованного кода, но можно все еще протестировать его в изоляции.