Автоматизированные тесты для функциональности «создать пользователя», требующие уникальных данных

Я пишу автоматизированные тестовые примеры в тестовой рамке Visual Studio 2017. Я тестирую часть «создать пользователя» веб-API. Пользователь должен быть создан с уникальным адресом электронной почты. После создания пользователя они не могут быть удалены.

Есть ли способ записи автоматизированных (запуск при проверке) тестовых примеров, которым нужны уникальные входные данные для каждого тестового прогона?

В приведенном ниже примере Имя пользователя должно быть уникальным для каждого вызова. Длина имени пользователя может составлять до 30 символов.

ProcessStudent(
    string StudentAuthId, 
    string FirstName, 
    string MiddleName, 
    string LastName, 
    string UserName, 
    string UserPassword
);

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

3 голоса | спросил Willis White 19 PMpThu, 19 Apr 2018 15:50:09 +030050Thursday 2018, 15:50:09

4 ответа


0

Я принял предложение cr3. Я использовал Bogus lib для C #. Используя Bogus lib и Microsoft.VisualStudio.TestTools.UnitTesting, я смог создать случайные тестовые данные для каждого который ему нужен. Я использовал слово «Очистить» в случайных данных, чтобы его можно было найти и удалить позже. Я хотел опубликовать пример, так как это то, что я искал изначально.

[TestInitialize]
    public void Initialize()
    {
        //Replace a formatted string with random numbers #, letters ?, or * random number or letter
        var faker = new Faker("en");

        StudentAuthIdRandom = new Bogus.Randomizer().Replace("???:???:???-Purge");
        FirstNameRandom = new Bogus.Randomizer().Replace("????-Purge");
        MiddleNameRandom = new Bogus.Randomizer().Replace("?????-Purge");
        LastNameRandom = new Bogus.Randomizer().Replace("??????-Purge");         
        UserNameRandom = new Bogus.Randomizer().Replace("????????-Purge");
        UserPasswordRandom = new Bogus.Randomizer().Replace("?*****-Purge");
    }

Примечание. Я узнал из других ответов, что то, что я делаю, является интеграционным (не единичным) тестированием, и для этого должна быть выделенная БД. Наличие выделенной БД для этой работы не было для меня вариантом, поэтому я использовал значения данных, которые можно было легко найти и удалить для используемого нами dev BD.

благодарим вас за ответы и предложения

ответил Willis White 2 Maypm18 2018, 15:16:25
2

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

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

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

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

ответил cr3 19 PMpThu, 19 Apr 2018 17:26:03 +030026Thursday 2018, 17:26:03
2

Ваша проблема в том, что ваш код обработки тесно связан с вашей БД, попробуйте развязку, и все будет намного проще:

class StudentProcessor
{
     Func<string, bool> CheckUsernameIsUnique;
     public StudentProcessor(Func<string, bool> checkUsernameIsUnique)
     {
         CheckUsernameIsUnique = checkUsernameIsUnique;
     }

     public ... ProcessStudent(...)
     {
         CheckUsernameIsUnique(username);
         ...
     }
}

Теперь гораздо проще проверить, что происходит здесь.

void Test()
{
     var processor = new StudentProcessor(x => {"username1", "username1"}.Contains(x));
     processor.ProcessStudent(...);
}

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

ответил TheCatWhisperer 19 PMpThu, 19 Apr 2018 22:27:05 +030027Thursday 2018, 22:27:05
-1

Похоже, вы пишете интеграционные тесты, для которых требуется живой веб-API. Если это так, совершенно нормально использовать API-интерфейс Live Web для тестирования, но вам нужно управлять базой данных.

Перед каждым тестированием очистите базу данных. Затем вставьте точно данные, необходимые для теста. Запустите тест. Утверждают. Промыть и повторить.

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

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

ответил Greg Burghardt 19 PMpThu, 19 Apr 2018 23:27:01 +030027Thursday 2018, 23:27:01

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132