Рубрика «Блог компании «ETNA Software»»

Когда нам нужно предоставить пользователю возможность графического редактирования содержимого на странице, пожалуй, чаще всего мы используем JavaScript для хранения данных и передачи их на сервер, и все споры ведутся вокруг способа отображения, внешнего вида редактора. Наш выбор простирается от простого HTML (с холстом или без) до встроенного SVG или использования Flash плеера.

Выбрать между этими вариантами не сложно: SVG подойдёт для схем или планов и другой векторной графики, холст больше подходит для фотографий или других изображений. Однако, оба этих элемента требуют «отделения» себя от страницы. Под «отделением» я имею ввиду то, что любой из этих элементов требует написания дополнительных сценариев для синхронизации вида с моделью.

Для небольших объектов, структура которых хорошо описывается деревом или списком (например, корзина покупателя или бизнес-процесс), использование HTML элементов для отображения и хранения данных могло бы упростить разработку и поддержку.
Читать полностью »

Даже если вы никогда в жизни не думали, что занимаетесь тестированием, вы это делаете. Вы собираете свое приложение, нажимаете кнопку и проверяете, соответствует ли полученный результат вашим ожиданиям. Достаточно часто в приложении можно встретить формочки с кнопкой “Test it” или классы с названием TestController или MyServiceTestClient.

Юнит тестирование для чайников

То что вы делаете, называется интеграционным тестированием. Современные приложения достаточно сложны и содержат множество зависимостей. Интеграционное тестирование проверяет, что несколько компонентов системы работают вместе правильно.

Оно выполняет свою задачу, но сложно для автоматизации. Как правило, тесты требуют, чтобы вся или почти вся система была развернута и сконфигурирована на машине, на которой они выполняются. Предположим, что вы разрабатываете web-приложение с UI и веб-сервисами. Минимальная комплектация, которая вам потребуется: браузер, веб-сервер, правильно настроенные веб-сервисы и база данных. На практике все еще сложнее. Разворачивать всё это на билд-сервере и всех машинах разработчиков?
Читать полностью »

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

Наблюдая со стороны это тестирование, я накопил некоторый объём информации, который, как я думаю, будет небезынтересен.

Камень 1-й. Коэффициент пересчёта

Тестирование таких приложений требует развёртывания целой сети тестовых машин. В итоге это приводит к образованию тестового кластера. Попытка развёртывания такого кластера на базе машин, физически стоящих в центре разработки, ведёт к созданию собственного датацентра со всеми издержками такого решения. Хорошей альтернативой стало использование решений типа Amazon Web Services.

Естественное желание сэкономить на аренде хостов или на покупке оборудования приводит к выбору таковых с заниженными относительно production инсталляции характеристиками. Заниженными в разы. И тут вступает в действие коэффициент пересчёта между синтетическими индексами производительности. Т.е. процессор в production будет в 2 раза быстрее, количество ядер будет в 4 раза больше, объём оперативной памяти будет в 6 раз больше, производительность дисковой подсистемы будет в 3,5 раза лучше, скорость сети будет в 100 раз больше. Сложим, поделим на количество показателей, умножим на некий поправочный коэффициент и получим коэффициент пересчёта, на который будем умножать результаты тестирования производительности. Можно придумать и более сложную формулу, например, назначить каждому показателю некий вес.

При ближайшем же рассмотрении такой подход оказывается пригодным лишь для подготовки тестовой сюиты для будущего тестирования на инсталляции, близкой к production, и на обнаружение самых очевидных проблем производительности. (Что уже достаточно много и важно.) Почему? Да потому хотя бы, что при таком подходе совершенно не учитывается эффект bottlenecks.Читать полностью »

Specification By Example – BDD для прагматиков
На Хабре довольно много упоминаний о BDD. К сожалению, статьи, которые я читал, так и не дали мне ответа на вопрос «а зачем мне все это нужно?» Ответ пришел с неожиданной стороны. Когда я всерьез занялся вопросом автоматизации приемочного тестирования, мне под руку попалась книга Gojko Adzic (не уверен в транскрипции, поэтому не стал переводить имя автора) Specification By Example.
Читая ее, я не уставал удивляться: каждая новая глава описывала шишки, которые я набивал на своем личном опыте, и предлагала решения аналогичные или лучшие, чем те, к которым я приходил сам методом проб и ошибок.

Эта статья – первая в цикле «BDD для прагматиков». В ней описаны ключевые элементы наиболее эффективного, на мой взгляд, процесса разработки коммерческого ПО в современных условиях. Два продолжения будут посвящены работе со SpecFlow и автоматизации приемочного тестирования.
Читать полностью »

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

В чем ее суть?

Проджект менеджер (ПМ) всегда видит, кто работает лучше, а кто хуже. Кто радеет за проект, а кто относится к работе формально. Кто постоянно выбивается из сроков, а кто успевает и еще тянет на себе отстающих. Кто постоянно предлагает какие-то улучшения, а кто ведет себя пассивно. Кто опаздывает на работу и на митинги, а кто проявляет постоянную пунктуальность. Кто пишет кривой код, а кто старается сделать свою работу качественной и считает для себя унизительным показывать коллегам некачественный код. Кто проверяет свою работу, стараясь минимизировать количество багов, а кто торопится, лишь бы отстреляться, а там хоть трава не расти.
«Добрый» ПМ редко или никогда не подходит к подчиненным и не указывает им на недостатки, не ругает за плохую работу. При этом, если что-то сделано хорошо, то большинство ПМов всегда рады похлопать сотрудника по плечу и сказать: «Ты молодец!»

К чему же приводит такая «доброта»?Читать полностью »