Ответы пользователя по тегу Модульное тестирование
  • Как писать тесты?

    EvilsInterrupt
    @EvilsInterrupt
    System programming, Reversing Engineering, C++
    Тесты для кого? Для человека или для машины?
    Я к тому, что тесты бывают разными: ручные и автоматические. Про это ничего не сказано в вашем вопросе!

    Какие именно тесты нужны? Модульные? Интеграционные? Инсталяции? Нагрузочные? Про это тоже ни слова в вашем вопросе!

    Тесты пишут так:
    1. Выявляют сначала рабочие сценарии, т.е. когда все хорошо и появляется результат. Есть огромное кол-во ситуаций, когда пользователь готов заплатить забажный продукт, если он хотя 1 раз и 50 запусков сделает ему то, чтобы он делал 3 дня! Сценарии сортируются по:
    1.1. компонентам
    1.2. приоритету и важности.

    После сортировки создают наборы тестов

    2. Далее выясняют сценарии, когда что-то не хватает "насяльника сеть упала, что делать?". Другими словами проверить работу позитивных сценариях при возможных негативных случаях, которые быть, но не повине пользователя. Примеры: сеть упала, флешка перстала видеться, в БД вдруг доступ не пускают и др. Особенно смотрят на возможную порчу исходных данных. Был у моего знакомого случая, когда они подбирали пароль к базе данных и случайно затерли пару байтов. ;)

    3. Только после этого проверяют "ошибку на дурака". Примеры: вместо текстового файла дали exe-файл. Или вместо числа ввели строку.

    Предположу, что вы хотите писать модульные тесты. Скажу следующее что эти типы тестов не должны делать:
    1. Проверять работу с БД, диском, сетью
    2. Код зависящий от времени

    Основной показатель модульного теста это скорость работы. Если тест такого типа работает пол-секунды, то значит вы написали что угодно, но это не модульный тест ;)
    Ответ написан
    1 комментарий
  • Где почитать про юнит-тесты?

    EvilsInterrupt
    @EvilsInterrupt
    System programming, Reversing Engineering, C++
    На системах какого масштаба их стоит начинать применять?


    К примеру нужно написать класс\метод и возникает вопрос "Когда остановиться?" другими словами, как понять что написанный код работает корректно? Можно глазками отсматривать каждую ветку кода. Можно поставить брэйкпоинты, чтобы посмотреть получаемые значения и в пределах допустимого они или нет. А можно по-другому:

    модульные тесты
    Ответ написан
    Комментировать
  • Flask тестирование?

    EvilsInterrupt
    @EvilsInterrupt
    System programming, Reversing Engineering, C++
    Есть книга от Мигеля Гринберга про Web-разработку с помощью Flask. Рекомендую прочитать разделы про тестирование. Я сознательно не буду приводить как, т.к. лучше Гринберга врядли кому-либо получится пояснить лучше. Но. Я бы хотел обратить ваше внимание на то, что лучше использовать не Nose, а py.test + pyhamcrest , тогда Ваши тесты будут более выразительными и вы будете лучше видеть "Что б.. сломалось то?"
    Ответ написан
    Комментировать
  • Как протестировать добавление элемента в список C#?

    EvilsInterrupt
    @EvilsInterrupt
    System programming, Reversing Engineering, C++
    Вы не можете начать тестировать только потому, что Вы решили сначала написать код, а только потом его тестировать. Это неверно! Когда принимается решение писать код, нужно хотя бы где-то описать его задачу. TDD почти один в один взяли подход от математиков. У математиков тоже есть "Дано" - это аналог SetUp и "Нужно сделать" - это аналог вашего тестируемого кода, т.е. то что Вы реализуете и "Чтобы удовлетворяло условиям...." - Это очень похоже на Assert.

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

    /Offtop:
    Рекомендую Вам выписать возможные случаи при добавлении элемента в список. К примеру:

    Позитивные случаи:
    * Добавить нормальный элемент;
    и т.д. и т.п.

    Негативные:
    * Добавить Null;
    * Добавить когда список уже переполнен - а такое возможно?;
    * Добавить когда список, когда не доконца создан - а такое возможно?
    и т.д. и т.п.
    Ответ написан
    Комментировать
  • Может ли юнит-тест метода класса зависеть также от других методов?

    EvilsInterrupt
    @EvilsInterrupt
    System programming, Reversing Engineering, C++
    Один тест - одна проблема. Тест должен выявлять СТРОГО одну проблему! Как вывод: не следует делать так, чтобы один тест зависил от другого.

    Мне кажется ВЫ не совсем верно понимаете что такое модульный тест. Вот его достаточно верное определение: Unit Test - Definition
    Ответ написан
    Комментировать
  • Как протестировать код который работает с shell командами?

    EvilsInterrupt
    @EvilsInterrupt
    System programming, Reversing Engineering, C++
    Ну вот Вы сами и сформулировали ответ на свой вопрос. Попробую пояснить. Модульный тест, хороший тест, обладает качеством: его просто написать! Даже вопроса не возникнет, о том, а как написать-то? Если же написать сложно, то Вы, возможно, пытаетесь написать тест на код в котором выполняется более чем одна задача!

    Сейчас вижу, что у Вас в методе выполнется минимум два не связанных между собою действия:
    1. Создание дескриптора
    2. Выполнение какого-то действия с применением этого дескриптора

    Их надо тестировать по отдельности! Для действия №1 Вы можете написать тесты:
    1. Позитивный: это когда 0, 1, 2
    2. Негативный: когда меньше нул или больше 2

    Для действия №2: Вы тоже можете написать минимум два теста с правильным и не правильным дескриптором
    Ответ написан
  • Как правильно тестировать классы?

    EvilsInterrupt
    @EvilsInterrupt
    System programming, Reversing Engineering, C++
    1.
    Приходят данные, как мне протестить их, может пришло не то!
    Для этого надо задать себе вопрос "А какие именно данные будут не теми?" и переписать их на листочке или же запомнить и держать в голове.

    2.
    >>Создавать доп базу?
    Нет! Для класса работающего с базой написать рефакторинг. Сутью рефакторинга перепроектировать на наследование этого класса работающего с БД от некоего интерфейса. Дальше от интерфейса породить несколько классов потомков на каждую ситуацию описанную в п.1. это будут моки, а вернее State-классы.

    Этот вид тестирования называется "State-based testing". Основан на том что заранее пишутся классы имеющее вполне заранее определенное и конкретное состояние, как правило захардкоженное(В data driven testing пока не вдавайтесь, ибо увязнете в деталях). Такие классы нужно писать как можно проще !!! Чтобы в будущем удалять код не было так жалко )))

    3)
    В тест-методах , т.е. в юнит-тестах вызываете production-код,но подставляете не реальную БД, а классы написанные п.2. и проверяете состояние.

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

    interface StudentDataBase:
      getName()
      getAge()
    
    // production code
    class OracleDataBase implements StudentDataBase
      getName()
      getAge()
    
    // For Testing goal
    class BadNameCorectAge implements StudentDataBase
      getName() {
        return 'Wrong-name'
      }
      getAge() {
        return 19;
      }
    
    TEST(WithBadNameForStudent) {
       // [1] Подготовительная часть. Т.е. 'Arrange' из паттерна Arrange-Act-Assert
        BadNameCorectAge database;
        // Здесь с псевдо-базой используется код из production-части, который вы хотите проверить
        TestObject testObj;
        testObj->setDataBase(database);
    
       // Выполняем действие в production-части и тут же проверяем 
      // [2] Другими словами это совмещенная Act-Assert из паттерна ArrangeAct-Assert
        EXPECT_EXCEPTION(testObj->process(), WrongNameException);
    }
    Ответ написан
    Комментировать