Стратегии создания тестовых данных, соответствующих классу/схеме, для тестов, управляемых данными

Ответ 1

Вам нужен инструмент, например NBuilder (http://code.google.com/p/nbuilder).

Это позволяет вам описывать объекты, а затем генерировать их. Это отлично подходит для модульного тестирования.

Вот очень простой пример (но вы можете сделать его как можно более сложным):

var products = Builder<Product>
                   .CreateListOfSize(10)
                   .All().With(x => x.Title = "some title")
                   .And(x => x.AnyProperty = RandomlyGeneratedValue())
                   .And(x => x.AnyOtherProperty = OtherRandomlyGeneratedValue())
                   .Build();

Ответ 2

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

Я работал с клиентом, у которого была аналогичная проблема, и они закончили тем, что хранили свои объекты как JSON и десериализовали их, ожидая, что их будет проще поддерживать и расширять. Это не так. Вы знаете, что не получается при редактировании JSON? Проверка синтаксиса времени компиляции. Они только что закончили тесты, из-за JSON, которые не смогли десериализоваться из-за синтаксических ошибок.

Одна вещь, которую вы можете сделать, чтобы уменьшить вашу боль, - это код для небольших интерфейсов. Если у вас есть гигантский объект с тонны свойств, данный метод, который вы хотите протестировать, вероятно, понадобится только для небольшого количества. Поэтому вместо вашего метода, принимающего SomeGiantClass, возьмите класс, реализующий ITinySubset. Работа с меньшим подмножеством сделает гораздо более очевидным то, что нужно заполнить, чтобы ваш тест имел какую-либо достоверность.

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

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

Ответ 3

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

http://research.microsoft.com/en-us/projects/Pex/

Ответ 4

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

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

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

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

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

Ответ 5

На самом деле, существует способ Microsoft выражать экземпляры объектов в разметке, и это XAML.

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

Почему я сделал бы это? потому что проект Visual Studio автоматически предоставит вам синтаксис XAML и, возможно, поддержку intellisense при добавлении этого файла.

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

Для справки, посмотрите:

• Создать объект из текста в XAML и
• Как конвертировать XAML файл в объекты и
• Как десериализовать XML-документ.

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