Keep Your Tests Clean: Refactoring

Published at February 25, 2019 ·  1 min read

Refactoring tests could be painful a lot. But it could also give you a lot of fun too. During refactoring unit tests, I’ve found a log of issues to be resolved. Also, it gives me more knowledge about how the project works.

Refactoring tests could be harder than refactoring rest of code because it could affect not only tests.

Since there are no tests for tests, there is only one way to understand if refactoring didn’t lead to less test coverage. It’s required to measure testsc overage before and after refactoring. New tests coverage should be equal to or more than the old one.

Run Django Tests in Parallel

Published at February 24, 2019 ·  2 min read

I’m wondering that in 2019 we still have a lot of tasks which are not parallelized yet. I’m pretty sure, that almost all laptops, desktops and even smartphones have more than one core on board.

In the meantime, I just realized that Django runs tests using only one process/core on my desktop. I’m disappointed but I think I know why it happens.

Many of us are not used to write concurrent code. Speaking about unit tests, it’s even worse. If you have a old project with a big amount of tests, I’m pretty sure that some tests could not be executed in a parallel. I’ll be happy if I’m wrong. But I think it’s only one reason that Django doesn’t add --parallel by default.

Code Coverage and Cyclomatic Complexity

Published at February 14, 2019 ·  1 min read

Code coverage for unit tests and cyclomatic complexity could be extremely useful metrics for your code. They help you to understand if something is not tested at all by unit tests. A combination of these metrics allows you to understand how many unit tests you should implement and what is your code complexity. I’m pretty sure, that everybody agrees that more coverage and less complexity is that you should aim for.

This test is too slow

Published at July 28, 2017 ·  1 min read

Sometimes we need to understand why unit-test is so slow. Sometimes I’m to lazy to go deep to understand why.

That’s why I’ve created a very simple profiled class to make unit-tests profiling fast and simple. I used only cProfile, so it will work on any Python project. It’s so simple, so I can’t talk about it more. You can install it via ‘pip install ProfiledTest’ and use it like:

TestFixtures - маленькая, но очень полезная библиотека

Published at January 11, 2013 ·  1 min read

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

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

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

Тестирование в Python: nose vs pytest

Published at February 25, 2012 ·  1 min read

Продолжаю сравнивать различные 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 |+ |+/- 

QUnit - тестируем JavaScript

Published at February 12, 2010 ·  1 min read

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

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

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

Unit тесты и наследование

Published at December 23, 2008 ·  1 min read

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

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

                //…             }         }

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

Миграция unit tests на Visual Studio 2008

Published at March 3, 2008 ·  1 min read

При миграции 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.