Давно решил не писать отзывы к библиотекам/фреймворкам, но эта поражает меня уже второй раз так, что в твиттере не помещается вся мысль.

TestFixtures (http://packages.python.org/testfixtures/) - приятное дополнение, а в некоторых случаях, и замена Mock.

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

Начиная от небольших функций, вроде generator и wrap, библиотека включает в себя то, из-за чего лично я ее использую: различные helper’ы для тестирования логгирования и вывода в потоки (stream’s) (когда-то очень помогла, найти ошибку и некорректным перехватом исключения и, вследствии чего, потерей части логов), а также всякие полезности для тестирования работы с датами и исключеними. 

Для меня это темерь однозначно must use в юнит-тестах.


 

Продолжаю сравнивать различные python-библиотеки. На этот раз выбор пал на два тест-фреймворка: nose и pytest. Первый позиционирует себя как unit test framework, второй - как для модульных, так и для функциональных и других тестов. Но так, как грань между модульными, интеграционными и функциональными тестами достаточно тонкая, то ее часто не замечают. Поэтому, эти библиотеки можно использовать для всех вышеперечисленных тестов.

Краткое сравнение функциональности фреймворков (тут я выбрал наиболее важные для меня вещи):

  nose pytest
Репозиторий  https://github.com/nose-devs/nose https://bitbucket.org/hpk42/pytest/
Дата последнего изменения 15.02.2012 6.02.2012 
Последняя версия 1.1.3 2.2.3 
Лицензия   As is 
Документация  +, подробная, легко разобраться +, подробная, легко разобраться 
Запуск определенного набора тестов +
Генерация отчета в формате xUnit +
Настройка детализации отчетов  +  
Изменение стандартного наименования
+
Поддержка fixtures fixeures, setup* и *teardown методы +, parametrized tests 
Интеграция с django +, сторонний плагин +, сторонний плагин 
Соответствие PEP8  +
Расширяемость +, механизм плагинов +, механизм плагинов 
Интеграция с setuptools  +/- 

Минимальными требованиями к фреймворкам все более-менее понятно. В обоих есть необходимые фичи. А так как, в данный момент, мне сложно предположить что потребуется в будущем, то выбирать придется исходя из удобства использования, что является достаточно субъективным критерием.

Nose. Легко писать тесты, если до этого был опыт работы со стандартным модулем unittests или ТеstNG/nUnit в Java и .NET соответственно.

pytest. Мне показался более легким для начинающих. Может из-за более удобной для меня документации, но времени на то, чтоб написать тест для “hello world” приложения мне потребовалось меньше, чем при использовании nose.

Что буду использовать на текущем проекте - пока не решил. Скорее всего, главную роль сыграют плагины для интеграции с django и continius integration


Разработчики JavaScript-фреймворка JQuery не перестают нас удивлять. После недавнего релиза JQuery 1.4.1 нам представили инструмент для unit-тестирования кода, написанного на JavaScript - QUnit

В данный момент поддерживаются такие функции как expect(), equals(), ok(), same(), log() и асинхронные тесты. Вместе с фреймворком распространяется css-файл, с помощью которого можно быстро и красиво выводить результаты тестов. Также разработчики активно используют его для тестирования самого JQuery, поэтому можно посмотреть уже готовые приверы от авторов фреймворка.

P.S. Что-то подсказывает мне что не загорами плагин для FireBug, по крайней мере, мне бы этого хотелось...


При разработке unit тестов в Visual Studio часто хочется создать какой-то базовый клас для тестирования базовой лоники. Например у нас есть такой класс:

 

        [TestClass]
        public class PersonTestBase
        {
            [TestMethod]
            public
virtual void GetNameTest()
            {

                //...
            }
        }

 и его класс наследник:
        [TestClass]
    public class CustomerTest: PersonTestBase
    {
        [TestMethod]
        public override void GetNameTest()
        {
            base.GetNameTest();
        }
    }

 Плюсы такого подхода:

  • полная поддержка визуальных средств Visual Studio (Test List Editor);
  • простота реализации.
Минусы:
  • избыточность кода;
  • создание наследника является по сути copy&paste.
Сразу необходимо заметить, что PersonTestBase и CustomerTest должны находится в одной сборке, иначе тесты в PersonTestBase работать не будут - это ограничение unit тестов. Подробнее смотрите в msdn. Кроме описанных в msdn способов можно поступить так:
  •  создаётся два проекта: BaseTests и CustomTests;
  • в проект CustomTests добавляются необходимые файлы из BaseTests таким образом: Project -> Add Existing Item -> Выбираем необходимые файлы -> Add As Link.
Таким образом физически файлы находятся в разных проектах, но при компиляции необходимые классы оказываются в одной сборке.
 
 Теперь пришло время изменить наш CustomerTest.
        [TestClass]
    public class CustomerTest: PersonTestBase
    {
        [TestMethod]
        public override void CustomerTestMethod()
        {
            //...
        }
    }
Мы добавили новый, специфический для Customer, метод и удалили переопределения метода из базового класса, т.к. его функциональность нас полность устраивает. Что мы из этого получили:
  • фактически, в классе у реализоано 2 тестовы метода: один перешел из базового класса и один мы реализовали сами.
  • Visual Studio Test List Editor говорит что у нас только один тетовый медов - метода из бащового класс не отображается и, соответственно, не запускается.
Обидно, но не смертельно. На помощь нам приходит штатная утилита MSTest , которая решает все, или почти все, наши проблемы.
Плюсы такого метода:
  • мы избавились от минусов предыдущего метода;
Минусы:
  • нету интеграции с Visual Studio. 

При миграции unit-тестов с Visual Studio 2005 на 2008 (.net 2.0) обнаружил интересный баг. Студия радостно отрапортовала об успешной конвертиции проектов, но при запустке тесты проваливались с такой ошибкой:

Method SampleTest.ClassDBTest.MyClassInitialize has wrong signature. Parameter 1 should be of type Microsoft.VisualStudio.TestTools.UnitTesting.TestContext.

Проверив инициализатор убедился что сигнатура метода правильная ещё раз запустил тесты, но они категорически отказывались работать. На компьюторе стояли две среды разработки: VS2005 и VS2008.
После внимательного изучения проекта выяснилось, что после миграции остался старый reference на сборку Microsoft.VisualStudio.QualityTools.UnitTestFramework версии 8.0. После изменения на новую версию 9.0 всё стало на свои места.
Надо отметить что в отчёте о конвертиции проектов никаких замечаний по этому поводу не было.