Накопилось несколько маленьких заметок/советов про python и django, которые на отдельные топики не тянут, поэтому публикую все сразу.

Под катом:

• как упростить код вьюх ровно в 2 раза
• легкий способ рисования графиков
• почему Ian Bicking воскликнул «Cool!»
• приложения для ВКонтакте на django за 5 минут
• хорош ли pymorphy?
• пара фишек насчет выкладки пакетов на pypi
• что общего между декораторами и with-контекст-менеджерами
• принимаем оплату на django-сайтах
• показываем Яндекс.Карту для заданного адреса

Последние дни всё чаще натыкаюсь на сообщения в блогах и форумах про то, что тестирование — это либо очень скучно, либо тупая работа и т.д.
Что все эти люди делают в тестировании??

Позавчера я тестировала свой небольшой веб-проект.

За 4 часа я завела 25 дефектов.

Я очень радовалась каждой «находке», особенно если в поиске она была нетривиальной. Ещё больше радовалась каждый раз, когда удавалось точно локализовать дефект. Мне действительно нравилось их заводить, стараясь это сделать наиболее понятным способом.

«А что, если?...», «А как проверить?...», «А как бы?...» и т.д. заполняют мозг, который включается на полную мощность.

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

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

И я задумалась. Кто пишет про «скучно», «рутина» и «тупая работа»? Почему не всем нравится? Постаралась выписать всё, что пришло в голову.

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

«Я не использую эту методологию (TDD) из-за того, что главный для меня вопрос остается без ответа. Я знаю, что использование TDD уменьшает количество багов, но что насчет времени, необходимого при работе по этой методологии?
Я хотел бы знать как изменяется время на разработку корпоративного приложения с использованием TDD — уменьшается, увеличивается или остается неизменным.
Надеюсь, вы сможете ответить, так как TDD и BDD меня очень интересуют.»

Moles – это легковесный тул от MS Research, который умеет автоматически генерировать заглушки для интерфейсов и виртуальных методов, а также для sealed классов, невиртуальных и статических методов (!), путем генерации кода, которому позднее можно будет подсунуть нужный делегат, вызываемый вместо определенного метода. Первый тип заглушек называется стабы (stubs), а второй – молы (moles). Именно эту штуку я использовал для тестирования асинхронных операций, о которых я рассказывал ранее, но давайте обо всем по порядку.

Stubs

Давайте рассмотрим такой пример. Предположим, что мы понимаем ценность модульных тестов, а также таких принципов, как Dependency Inversion, и других безумно полезных принципов и паттернов (может быть всех остальных принципов S.O.L.I.D., а возможно даже и F.I.R.S.T.). И дело даже не в том, что мы фанаты тестов или дядюшки Боба, а просто потому, что мы знаем, что высокая связность – это плохо. Поэтому мы стараемся в разумных пределах уменьшить зависимости путем выделения интерфейсов с последующим «инжектом» их в конструкторы классов или в методы, которым эти интерфейсы необходимы для выполнения своих задач.

Tarantool — это открытое, высокопроизводительное хранилище данных. Такие характеристики системы, как простота и производительность, во многом определяют область её применимости. На шкале решений для хранения данных Tarantool находится где-то посередине между традиционными реляционными системами, такими как MySQL, и решениями для кэширования данных, такими как memcached. В основе системы лежит персистентное хранилище данных, полностью отображённое в оперативную память, и высокопроизводительные индексы для доступа к данным на основе хэшей и бинарных деревьев.

В мои первые месяцы работы над Tarantool я попытался создать инструментарий тестирования, похожий на тот, что был в моём предыдущем проекте с открытым исходным кодом — MySQL.

Как говорится: «Запретный плод сладок», так и у меня. Попробовав однажды писать тесты на RSpec, хочется иметь декларативный BDD DSL в каждом языке. Вот например JavaScript, имеет аналоги mocha.js, jasmine.js, etc. Но нет, мало. Хочется не просто всяких describe-ов или it-ов, а еще и ленивых переменных, я имею в виду subject и let.

На первый взгляд глупо! Внутренний голос кричит «Зачем?», а совесть в ответ: «Чистый код — это важно! Ну а простые тесты — вообще мега важно!».

Вот так и родилась библиотека для mochajs, которая позволяет создавать ленивые переменные (aka let) и `subject`.

Для тех кто понимает о чем я и уже напрягся засветился от радости, милости просим на Github.
Всем остальным, а в особенности скептикам предлагаю заглянуть под cut.

Привет, Хабражители!

Не так давно была написана вводная статья, которая кратко объясняла базовый функционал проекта FIXber — рынка услуг по тестированию программного обеспечения.



С тех пор мы доработали новый функционал и значительно переработали старый.
И вот сейчас, как и обещали, мы готовы предоставить вам проект на «пощупать».

Привет, Хабражители!

Прошло две недели после закрытого запуска площадки FIXber (рынка услуг по тестированию ПО).
Мы получили от тестировщиков и заказчиков огромное кол-во фидбэков из которых большая часть была действительно полезных, часть не очень — видимо из-за не глубокого понимания того, что мы здесь «навояли».

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



На днях мы собрали немного статистики и готовы поделиться с вами реальными цифрами — основные активности тестировщиков и заказчиков находятся под катом.

Привет, Хабражители!

Сегодня с утра в полноценном режиме мы запустили площадку для проведения тестирования FIXber и будем рады видеть у нас всех тестировщиков и заказчиков, которые заинтересованы в тестировании своих проектов.

За месяц мы проделали огромное кол-во работы, изменив существующий функционал под требования тестировщиков и заказчиков, и доработав новый — делаем всё, чтобы каждому было удобно пользоваться площадкой.



Список текущего функционала и новых доработок площадки под катом.

     «Милая „Наталья“, я вам пишу, чего же… » Нет, не такое вступление должно быть для монолога в стиле Роберта Пирсига. Такое обращение оставим для диалога в комментариях.

Книгу Дзен и искусство ухода за мотоциклом я рекомендую всем, кому важно качество, особенно тем, кто близок к тестированию!

Привет, Хабражители!

Сегодня мы обновили FIXber — площадку услуг по тестированию ПО и всем, кому интересно, предлагаем ознакомиться с новыми доработками.

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



Описание новых возможностей площадки (со скриншотами) под катом.

Привет, Хабражители!

Сегодняшний пятничный пост я посвящаю всем разработчикам программного обеспечения, которые делают нашу жизнь проще и интереснее, и расскажу вам как уже через 30 минут узнать много нового о своём ПО и получить первые дефекты, используя нашу площадку для тестирования FIXber.

Задача тестировщика заключается не просто в нахождении дефектов, а в общем улучшении качества программного продукта.

Всем кому интересно, прошу пожаловать под катом.

Дорогие хабровчане, хочу обратить ваше внимание на грядущий выпуск Ubuntu, и предлагаю принять участие в тестировании новой версии этого замечательного дистрибутива. До релиза осталось немногим больше недели, и у нас ещё есть шанс помочь разработчикам сделать «нарвала» действительно «опрятным». На сегодняшний день Ubuntu достаточно стабильна, но содержит некоторое количество багов, на которое следует обратить внимание разработчиков до релиза. В этом посте я предлагаю делиться найденными багами, подтверждать на launchpad, что баг у вас проявляется, и коллективно писать новые репорты.

Все, кто занимается мобильным вебом, обязательно сталкиваются с проблемой тестирования на различных платформах. С одной стороны, тестировать надо на реальных устройствах, с другой стороны многие компании не могу достаточно быстро собрать парк нужных устройств. Сегодня я хотел бы написать про браузерный эмулятор для тестирования мобильных платформ под названием Ripple Emulator.

Сегодня все большую популярность приобретает test-driven development(TDD), техника разработки ПО, при которой сначала пишется тест на определенный функционал, а затем пишется реализация этого функционала. На практике все, конечно же, не настолько идеально, но в результате код не только написан и протестирован, но тесты как бы неявно задают требования к функционалу, а также показывают пример использования этого функционала.

Итак, техника довольно понятна, но встает вопрос, что использовать для написания этих самых тестов? В этой и других статьях я хотел бы поделиться своим опытом в использовании различных инструментов и техник для тестирования кода в Java.

Ну и начну с, пожалуй, самого известного, а потому и самого используемого фреймворка для тестирования — JUnit. Используется он в двух вариантах JUnit 3 и JUnit 4. Рассмотрю обе версии, так как в старых проектах до сих пор используется 3-я, которая поддерживает Java 1.4.

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

Привет, Хабражители!

Уже довольно давно мы не писали постов о площадке услуг по тестированию ПО Fixber.com, и вот сейчас мы готовы рассказать вам, что же интересного и нового появилось на ней за это время.

Есть как интересные масштабные изменения, так и небольшие, но от этого не менее важные.



Всем кому интересно, добро пожаловать под кат.

Случайно наткнулся на свеженаписанную утилиту ioping, написал её русский программист koct9i, пользователь k001 оформил в rpm для fedora 14 . ioping на google code.
А пользователь Grohman собрал ебилд, а LupineDreamer сделал деб-пакет i386 и x64 от magzimko.

Выглядит это дело примерно вот как:
$ ioping -i 0.2 -c 6 -s 1M -S 10M /tmp
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=1 time=0.7 ms
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=2 time=191.3 ms
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=3 time=18.4 ms
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=4 time=12.4 ms
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=5 time=8.4 ms
1048576 bytes from /tmp (ext3 /dev/mapper/VolGroup00-LogVol00): request=6 time=8.2 ms

Наверняка все знакомы с таким понятием как test-driven development(TDD). Наряду с ним также существует такое понятие, как data-driven testing(DDT, не в обиду Шевчуку) — техника написания тестов, при которой данные для тестов хранятся отдельно от самих тестов. Они могут храниться в базе данных, файле, генерироваться во время исполнения теста. Это очень удобно, так как один и тот же функционал тестируется на различных наборах данных, при этом добавление, удаление или изменение этих данных максимально упрощено.

В предыдущей статье я рассмотрел возможности JUnit-а. Там примерами такого рода подхода могут служить запускалки Parameterized и Theories, в обоих случаях один тест-класс может содержать только один такой параметризированный тест(в случае Parameterized несколько, но все они будут использовать одни и те же данные).

В этой статье я заострю внимание на тестовом фреймворке TestNG. Многие уже слышали это название, и перейдя на него, вряд ли желают вернуться к JUnit-у(хотя это только предположение).

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

Краткое содержание поста:

1. тестирование веб-сайтов — это сложно и непонятно
2. юнит-тесты в django
3. тестовая БД и как с ней бороться
4. smoke testing
5. покрытие кода (code coverage)