Такой подход в некоторых случаях может привести к тормозам и низкой скорости ответа пользовательского интерфейса. Расскажу когда так бывает и как с этим бороться…

Почему может «тормозить» Service

Каждое Android-приложение по-умолчанию запускается в отдельном процессе. В каждом процессе запускаются потоки (Thread). По-умолчанию все компоненты приложения (Activity, Service, BroadcastReceiver) запускаются в одном «main» потоке (он же UI-thread). Если внутри сервиса запустить, например, долгий сетевой вызов или какую-то тяжелую инициализацию, мы получим тормоза всего приложения, его интерфейса и, скорее всего, предложение сделать Force close… Впрочем, работа службы в том же потоке, что и остальное приложение, имеет свои плюсы – у вас есть доступ к элементам интерфейса. Если бы служба работала в другом потоке, доступ к UI у вас бы отсутствовал.

Что делать?

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

Для запуска задачи в отдельном потоке можно воспользоваться следующими средствами SDK:

• создать Thread
• использовать AsyncTask

Запускаем свой поток

Поток создать просто…

Thread myThread = new Thread(new Runnable() {
    @Override
    pubic void run() {
        doLongAndComplicatedTask();
    }
});

myThread.start(); // запускаем

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

final TextView txtResult = (TextView)findViewById(R.id.txtResult);
Thread myThread = new Thread(new Runnable() {
    @Override
    public void run() {
        txtResult.setText(doLongAndComplicatedTask());
    }
});

myThread.start();

В результате выполнения получим ошибку. «Чужой» поток попытался обратиться к UI! Как вылечить? Надо использовать Handler. Доработаем код…

final Handler myHandler = new Handler(); // автоматически привязывается к текущему потоку.
final TextView txtResult = (TextView)findViewById(R.id.txtResult);
Thread myThread = new Thread(new Runnable() {
    final String result = doLongAndComplicatedTask();
    myHandler.post(new Runnable() {  // используя Handler, привязанный к UI-Thread
        @Override
        public void run() {
            txtResult.setText(result);         // выполним установку значения
        }
    });
});

myThread.start();

AsyncTask – все проще

Для реализации подобных задач в Android SDK имеет встроенное средство – AsyncTask. Данный класс позволяет не думать о том, в каком потоке выполняется ваш код, все происходит автоматически. Рассмотрим пример выше переписанный на AsyncTask.

class LongAndComplicatedTask extends AsyncTask<Void, Void, String> {

    @Override
    protected String doInBackground(Void... noargs) {
        return doLongAndComplicatedTask();
    }

    @Override
    protected void onPostExecute(String result) {
        txtResult.setText(result);
    }
}

AsyncTask longTask = new LongAndComplicatedTask(); // Создаем экземпляр
longTask.execute(); // запускаем

Метод doInBackground будет выполнен в отдельном потоке, результат его выполнения будет передан в метод onPostExecute, который, в свою очередь будет выполнен на UI-Thread’е
Следует помнить, что:

• AsyncTask может выполняться лишь раз. Для повторного запуска нужно пересоздать класс;
• execute() должен быть выполнен на UI-Thread’е.

А что делать, если задачу нужно выполнять регулярно, через определенные промежутки времени…

Таймер. Самый простой подход к периодическому запуску.

Java предоставляет Timer для запуска повторяющихся задач. Сделаем так, чтобы AsyncTask из предыдущего примера выполнялся раз в минуту…

Timer myTimer = new Timer(); // Создаем таймер
final Handler uiHandler = new Handler();
final TextView txtResult = (TextView)findViewById(R.id.txtResult);
myTimer.schedule(new TimerTask() { // Определяем задачу
    @Override
    public void run() {
        final String result = doLongAndComplicatedTask();
        uiHandler.post(new Runnable() {
            @Override
            public void run() {
                txtResult.setText(result);
            }
        });
    });
}, 0L, 60L * 1000); // интервал - 60000 миллисекунд, 0 миллисекунд до первого запуска.

Стоит заметить, что все упрощается если «долгоиграющая» задача не требует доступ к UI. В этом случае не требуются ни Handler’ы, ни AsyncTask’и.

Кстати, у таймера есть еще метод scheduleAtFixedRate(). Различия между ним и schedule() описаны в документации.

Более гибкий способ. ScheduledThreadPoolExecutor.

Класс ScheduledThreadPoolExecutor указан как рекомендуемая альтернатива использованию Timer. Данный класс позволяет организовать пул потоков и планировать выполняемые задачи относительно него. Т.е. класс для организации очереди заданий один, но тем не менее он может выполнять одновременно несколько заданий, если это позволяет имеющееся количество доступных потоков. Более подробно о преимуществах – в документации.

Для каждого заплаированного задания доступен его «дескриптор» – ScheduledFuture с помощью которого можно, например, отменить выполнения одного конкретного задания не трогая весь остальной пул.

Задание со звездочкой. Велосипед. Thread, Looper, Handler.

А еще можно собрать свой велосипед поток с очередью.

public class LoopingThread extends Thread {
    private CountdownLatch syncLatch = new CountdownLatch(1);
    private Handler handler;

    public LoopingThread() {
        super();
        start();
    } 

    @Override
    public void run() {
        try {
            Looper.prepare();
            handler = new Handler();
            syncLatch.countDown();
            Looper.loop();
        } catch(Exception e) {
            Log.d("LoopingThread", e.getMessage());
        }
    }

    public Handler getHandler() {
        syncLatch.await();
        return handler;
    }
}

Thread loopThread = new LoopingThread(); // будет выполняться вечно
loopThread.getHandler().post(new Runnable() {
    @Override
    public void run() {
        doLongAndComplicatedTask();
    }
});

Данный поток, будучи единожды запущенным, выполняется вечно. Для общения с ним (отправки заданий) можно использовать метод getHandler() для получения хандлера и дальнейшей отправкой «событий» в него. CountdownLatch используется для синхронизации, чтобы поток, желающий получить Handler, не получил его ранее того момента, когда поток-работник запустится и Handler буде создан.

За время пользования я обнаружил для себя некоторые субъективные достоинства но есть один объективно важный для разработчика плюс. На маке все есть. Покупая Mac в нем уже есть из коробки

• Python
• Perl
• PHP
• Ruby
• … ну и еще много всего

К чему бы все это богатство нужно если вы, например, PHP-программист, веб-разработчик которому это все барахло совсем даже поровну, что есть что нет… Все дело в сторонних инструментах. Возьмем например SASS. Написан он на Ruby. И вот на винде тебе нужно пойти, найти и скачать инстяллятор, накатить это все, потом уже накатить  SASS… На Mac ты просто пишешь в консоли gem install sass и начинаешь пробовать.

Та же песня со всякими вещами типа Node.JS и NPM к нему. На винде нужно уметь плясать с правильной моделью бубна чтобы все это зажило (до 6 версии по крайней мере это было так). Здесь ты просто выполняешь не сильно сложные инструкции с сайти или качаешь готовый дистр и уже можно начинать экспериментировать с новым инструментом.

Есть сайт – статика + ISAPI-расширение. Статика на 90% состоит из XML и JS. Ее много.

Вот диаграмма загрузки кучи статики в Firefox. Как видно – все в порядке.

А теперь то же самое в IE8.

На обоих изображених подчеркнуты запросы с одинаковым размером (чтобы было проще ориентироваться). Порядок разный потому что вызывают их различне асинхронные процессы и это (порядок) для работы приложения не важен.

Видно 3 проблемных места. В точке 1 запросы начали подтормаживать (темно зеленый – время отдачи контента, по размеру видно что отдавать там нечего). Следующая пачка параллельных запросов (точка 2) зависает еще сильнее (до 5 сек.), и снова по размеру понятно что не на чем там столько сидеть. Следующая проблемная точка (3) висит уже не на отдаче, а на приеме сервером (?, в легенде это называется «send first to last») пакета данных (POST) и снова по размеру понятно что отправлять там целых 1.5 сек. совершенно нечего…

На сервере IIS 7.5, замеры проводились на одной и той же клиентской машине в одно и то же время. Проблема не зависит от клиентской машины и проявляется на других маинах в сети аналогичным образом. В Event log’е винды пусто.

После загрузки и распаковки APK (вспоминаем что APK это просто ZIP-архив) в нем обнаружилась «набивка» из 153 PNG файлов (переименованных зачем-то в .temp) со свидетелем из Фрязино и собственно «приложение»…

Как и следовало ожидать, от оригинального приложения там ничего не осталось. Ни иконки, ни, тем более, кода. А при дальнейшем рассмотрении (похоже что) ВСЕ файлы на androides-os.com – одна и та же программа! Я скачал несколько разных программ из разных разделов и все они были одного размера и с одинаковым содержимым!

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

Чистый Java-код нам из APK не получить, но можно получить набор инструкций VM Dalvik, который вполне читается глазами без дополнительного софтового обеспечения. С помощью утилиты dexdump из Android SDK сдампим набор инструкций Dalvik в файл…

dexdump -d -f -h classes.dex > dump.dump

Поскольку предполагается, что приложение отправляет SMS, поищем в дампе строку «sendTextMessage» – это функция SDK, предназначенная для отправки текстовых сообщений. Поиск оказывается успешным, находится одно вхождение в методе activate()

Вкратце основные детали метода (получено путем ручной «декомпиляции» dalvik-инструкций):

        // private HashMap<String, ActivationScheme> activationSchemes;
        // private static String CURRENT_ACTIVATION_SCHEME = "1";

        ActivationScheme o = activationSchemes.get(CURRENT_ACTIVATION_SCHEME);

        ArrayList<Pair<String, String>> l = o.list;
        // first - номер куда слать
        // second - что слать?

        for(Pair o2: l) {
            StringBuilder b;
            String sec = String.valueOf(o2.second); // WTF???
            b = new StringBuilder(sec);
            b.append("+");
            String s3 = schemes.get("2"); // private HashMap<String, String> schemes;
            b.append(s3);
            String result = b.toString(); // "pair.second"+schemes[2]
            String frst = o2.first; // v1
            // mgr == TelephonyManager
            mgr.sendTextMessage(frst, null, result, /* PendingIntent.getBroadcast(...) */, null);
        }

Т.е. имеется некий набор «схем активации» состоящих из списка пар строк, одна из которых номер на который слать СМС, а другая – что собственно слать.
Попробуем найти схемы активации… в дампе имеется метод initActivationSchemes где можно найти вот такой код:

        ArrayList al = new ArrayList();
        if("250".equals(currentMCC)) { // MCC == Mobile Country Code

            ArrayList<Pair<String, String>> aP = new ArrayList<Pair<String, String>>(); 

            Pair<String, String> p = new Pair<String, String>("4129", "bb031");
            aP.add(p);

            p = new Pair<String, String>("4129", "bb031");
            aP.add(p);

            ActivationScheme sc = new ActivationScheme(aP);
            activationScheme.put(CURRENT_ACTIVATION_SCHEME, sc);
        }

Т.е. для России (MCC == 250) создается активационная схема из отправки двух СМС на номер 4129… Метод наряду с MCC 250 имеет и другие коды стран, и, соответственно, схемы активации для них. Для каждой страны подобрали определенный платный номер.

Тут есть некоторая непонятка. Несмотря на то, что 250 – Россия, номер 4129 (по крайней мере по информации которую я смог найти) пробивается как Украинский. Возможно я допустил ошибку при «декомпиляции» и случайно «записал» в Российский блок коды для Украины…

Собственно как выглядит приложение…
Install – это оно:

При запуске все очень незамысловато:

Есть даже «оферта»:

Такая же «оферта» судя по всему доступна вот тут: http://depositfmobi.ru/ofert
На сайт вышел по названию package приложения: com.depositmobi.

Что интересно, это depositmobi и «QIP.Файлы» и «Rapidshare» одновременно!

Что в итоге? Очень просто способ мошенничества. Делаем сайт, прокачиваем для него SEO по нужным ключевым словам, накачиваем туда тематических новостей и заполняем его простейшей программой отправки СМС на платные номера снабдив ее «офертой» чтобы прикрыть задницу… Можно ли что-то сделать с такими товарищами законными путями?

• Это было супер офигенски круто. Организация, доклады, атмосфера – все на высоком уровне. Спасибо оргам. Робот Марвин свободно ездящий по территории – это 5. Мешки, юла-стулья, тематические мероприятия («Настрой Ngninx за 10 минут») и стенды – просто супер.
• Доклад Алексея Воинова про экзотические языки – замечателен, смело меняем название на «Зачем программисту ходить на технические конференции» и вкладываем в уши всем работодателям, кто еще сопротивляется отпускать своих сотрудников, мотивируя практической бесполезностью происходящего.
• Роботы, тестирующие веб-сервисы от Артема Ерошенко – супер, отличная идея методики автоматизированного тестирования верстки.
• Познакомился с Дмитрием @dr_zhest Жестилевским. Отлично выпили пива и пообщались в кабаке после мероприятия =)
• Из грусти: WiFi – его качество немного скрашивало позитив. Если на его отсутствие во время докладов можно было смело забить, то отсутствие его на мастер-классах по BEM сделало участие в них крайне сложным. Возможно помогли бы шнурки или отдельная запароленная сеть с выдачей доступов на самом мастер-классе. Впрочем, как правильно заметил bobuk на круглом-столе – WiFi всегда проблема на подобных мероприятиях.
• И все же, то, как Яндекс в BEM использует NodeJS, натолкнуло на определенные практические мысли относительно текущего рабочего проекта. Profit!

Еще раз Спасибо всем организаторам и докладчикам за офигенское мероприятие. Ждем YaC 2012!

Обычно при внезапном падении приложения Android предлагает отправить отчет об ошибке, где будет и подробный стэк-трейс и информация о версии вашего приложения. К сожалению пользователи не всегда нажимают кнопку «отправить отчет» а для дебаг-приложений или приложений не из маркета такая функциональность и вовсе недоступна.

Что же делать? На помощь приедет возможность языка Java обрабатывать исключения (Exceptions), в том числе и непойманные (unhandled).

Класс Thread имеет статический метод setDefaultUncaughtExceptionHandler. Данный метод позволяет установить собственный класс-обработчик непойманных исключений. Класс-обработчик должен имплементировать интерфейс Thread.UncaughtExceptionHandler. Каркас обработчика может выглядеть примерно так:

public class TryMe implements Thread.UncaughtExceptionHandler {
    @Override
    public void uncaughtException(Thread thread, Throwable throwable) {
        Log.d("TryMe", "Something wrong happened!");
    }
}

Единственный метод принимает на вход Thread – поток, в котором произошло исключение, и Throwable – само исключение. Приведенная выше реализация просто выводит в лог сообщение без каких либо деталей… Попробуем воспользоваться…

public class MainActivity extends MapActivity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        Thread.setDefaultUncaughtExceptionHandler(new TryMe());

        Integer a=1;
        if(true)
            a=null;
        int x = 6;
        x=x/a;  // Exception here!
    }
}

После запуска вышеприведенного кода мы (ура!) получим сообщение в логе… и черный экран. Установив наш собственный обработчик мы удалил штатный обработчик ОС Android и теперь нам больше не предлагают закрыть приложение.

Исправим положение

public class TryMe implements Thread.UncaughtExceptionHandler {

    Thread.UncaughtExceptionHandler oldHandler;

    public TryMe() {
        oldHandler = Thread.getDefaultUncaughtExceptionHandler(); // сохраним ранее установленный обработчик
    }

    @Override
    public void uncaughtException(Thread thread, Throwable throwable) {
        Log.d("TryMe", "Something wrong happened!");
        if(oldHandler != null) // если есть ранее установленный...
            oldHandler.uncaughtException(thread, throwable); // ...вызовем его
    }
}

Теперь мы видим и сообщение в логе, и привычное системное сообщение.

Неудобно устанавливать обработчик в Activity. Хоть он и будет установлен а все потоки, но Activity может быть несколько и несколько же стартовых. А еще могут быть сервисы… В этом случае лучше всего устанавливать обработчик при инициализации приложения. Примерно вот так:

public class MyApplication extends Application {
    @Override
    public void onCreate() {
        Thread.setDefaultUncaughtExceptionHandler(new TryMe());
        super.onCreate();
    }
}

При этом нужно не забыть прописать новый класс приложения в манифест. Примерно вот так:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="my.package">
    <application
        android:name="MyApplication" ...

Теперь при старте приложения (не важно какого его компонента) будет установлен обработчик исключений.

Конечно выводить сообщение в лог это не серьезно. Нужно собирать больше информации. Какая версия приложения? Какое исключение не обработано? Какое другое исключение привело к выбросу фатального? В каком потоке? Какой был стэк? Всю эту информацию можно получить. Код простейшего обработчика исключений получающий и сохраняющий на SD-карту всю вышеуказанную информацию размещен на GitHub.

Приведенная реализация сохраняет информацию об необработанном исключении в файл на SD-карте в папку /Android/data/your.app.package.name/files/ (так велит Dev Guide) в файлах вида stacktrace-dd-MM-yy.txt. Для работы в манифесте приложения требуется разрешение WRITE_EXTERNAL_STORAGE.

Естественно это не единственное подобное решение.

Flurry - аналитика для мобильных приложений, содержит свой обработчик ошибок. ACRA - библиотека для Android, собирает данные об ошибках и постит их на GoogleDocs. Android-remote-stacktrace – аналогичная библиотека, шлет данные на пользовательский скрипт-приемник. Также много полезного можно получить в этом вопросе на StackOverflow

Суть в следующем. Если после onCreate в вашей TabActivity внутри TabHost не будет создано ни одной корректной вкладки все хозяйство с треском осыпается. Причем стэк очень интересный. По нему сложно выявить причину ибо в нем нет ничего, кроме кода ядра ОС.

Выглядит примерно так

Exception: java.lang.NullPointerException
Message: null
Stacktrace:
        android.widget.TabWidget.dispatchDraw(TabWidget.java:241)
        android.view.ViewGroup.drawChild(ViewGroup.java:1565)
        android.view.ViewGroup.dispatchDraw(ViewGroup.java:1294)
        android.view.ViewGroup.drawChild(ViewGroup.java:1565)
        android.view.ViewGroup.dispatchDraw(ViewGroup.java:1294)
        android.view.ViewGroup.drawChild(ViewGroup.java:1565)
        android.view.ViewGroup.dispatchDraw(ViewGroup.java:1294)
        android.view.View.draw(View.java:6588)
        android.widget.FrameLayout.draw(FrameLayout.java:383)
        android.view.ViewGroup.drawChild(ViewGroup.java:1567)
        android.view.ViewGroup.dispatchDraw(ViewGroup.java:1294)
        android.view.View.draw(View.java:6588)
        android.widget.FrameLayout.draw(FrameLayout.java:383)
        com.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:1869)
        android.view.ViewRoot.draw(ViewRoot.java:1384)
        android.view.ViewRoot.performTraversals(ViewRoot.java:1149)
        android.view.ViewRoot.handleMessage(ViewRoot.java:1668)
        android.os.Handler.dispatchMessage(Handler.java:130)
        android.os.Looper.loop(Looper.java:154)
        android.app.ActivityThread.main(ActivityThread.java:4416)
        java.lang.reflect.Method.invokeNative(Native Method)
        java.lang.reflect.Method.invoke(Method.java:552)
        com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:910)
        com.android.internal.os.ZygoteInit.main(ZygoteInit.java:668)
        dalvik.system.NativeStart.main(Native Method)

Лечится, очевидно, корректной подготовкой табов в onCreate. Что интересно, в 2.2 такого бага уже нет.

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

О том, как можно Unit-тестировать JavaScript я писал ранее, сейчас же расскажу о процессе интеграционного тестирования, применяемого в команде.

Selenium

С давних времен известен инструмент тестирования веб-приложений/страниц в браузере – Selenium. В плане его применения есть два основных пути, а именно:

1. написание TestSuite в SeleniumIDE и прогон их через SeleniumTestRunner, или
2. использование WebDriver

WebDriver это новая «фишка» Selenium, появившаяся во второй ветке продукта. Основная его суть – можно гонять тесты, описанные в коде (C#, Java), в разных браузерах и/или в виртуальной среде исполнения.

WebDriver

Selenium WebDriver это набор «биндингов» к разным языкам (C#, Java), позволяющий отдавать различные команды «подчиненному» браузеру.

Для каждого браузера имеется своя реализация WebDriver (FireFoxDriver, InternetExplorerDriver, ChromeDriver – сейчас включены в поставку, OperaSoftware разработали OperaDriver). Существует также «виртуальный» HtmlUnitDriver. В отличии от «браузерных» реализаций он не требует установленного браузера и за счет этого работает быстрее и платформонезависим, но есть и минусы – HtmlUnitDriver имеет «свою» реализацию JavaScript и потому поведение «богатых» веб-приложений может в нем отличаться. Для своих задач мы используем «браузерные» реализации, это позволяет проверить приложение именно в той среде, в которой оно будет исполняться впоследствии.

Кратко общая суть работы с WebDriver может быть описана так:

• реализуется код, использующий какую-либо имплементацию WebDriver. Данный код выполняет какие-либо действия с веб-страницей и сравнивает результат с эталонным
• WebDriver транслирует команды в запущенный браузер (при использовании «браузерной» реализации) и сообщает результаты «обратно в код»

Что умеет WebDriver

Ниже рассматривается «браузерная» реализация, суть расширение класса RemoteWebDriver (реализует интерфейс WebDriver).

• поиск элементов: findElement(s)By*
  • CssSelector
  • ClassName
  • Id
  • LinkText
  • TagName
  • XPath
• загрузка страницы, получение контента страницы
• исполнение произвольного JavaScript
• осуществление операций Drag-n-Drop

C «найденными» элементами (интерфейс WebElement)

• получение текста (text)
• получение значения (value)
• click по элементу
• ввод с клавиатуры (клавиша, сочетание клавиш, последовательность клавиш/сочетаний)

Среда исполнения тестов

В качестве языка для написания тестов была выбрана Java. Среда для исполнения – JUnit4.

Базовый абстрактный класс веб-тестов.

@Ignore
abstract public class AbstractWebTest {

    protected static RemoteWebDriver _driver;
    // расположение тестовой страницы
    private String testPageLocation =
                String.format(
                        "http://%s:%s/test.html",
                        System.getProperty("test.httproot"),         // Web-сервер ...
                        System.getProperty("test.httpport", "80")   // и порт
                );
    // Используемая имплементация WebDriver
    private static String driverName =
                System.getProperty(
                        "test.driver",
                        "org.openqa.selenium.firefox.FirefoxDriver");

    /**
     * Перед каждым набором тестов - создаем инстанс драйвера.
     * Это автоматически запустит браузер
     */
    @BeforeClass
    public static void setUpDriver()
                throws ClassNotFoundException,
                          IllegalAccessException,
                          InstantiationException {
        _driver = (RemoteWebDriver) Class.forName(driverName).newInstance();
    }

    /**
     * Перед каждым тестом - открываем тестовую страницу
     */
    @Before
    public void setUp() {
        _driver.get(testPageLocation);
    }

    /**
     * После каждого набора тестов - закрываем инстанс дарйвера (закрываем браузер)
     */
    @AfterClass
    public static void tearDown() {
        _driver.close();
    }
}

Конкретный класс с набором тестов (для простоты убраны некоторые проверки, например на то, что элемент по CSS-селектору действительно найден и доступен на странице)

public class TestMoneyField extends AbstractWebTest {

    /**
     * При рендеринге поле ввода денежной суммы должно показать 0.00
     */
    @Test
    public void testRendering() {
        WebElement content =
           _driver.findElementByCssSelector("#FieldMoney .input-text-field");
        Assert.assertEquals("0.00", content.getValue());
    }

    /**
     * Проверим форматирование "триад"
     */
    @Test
    public void testInputWithoutDot() {

        WebElement content =
           _driver.findElementByCssSelector("#FieldMoney .input-text-field");
        content.sendKeys("999999");
        Assert.assertEquals("999 999.00", content.getValue());
    }
}

Все тесты запускаются с помощью отдельного таска Ant-билда:

<target name="integrationtest" depends="init, buildtests, deploytests">
   <junit haltonfailure="false">
      <sysproperty key="test.driver" value="org.openqa.selenium.firefox.FirefoxDriver" />
      <classpath>
         <pathelement location="${path.to.tests.jar}"/>
      </classpath>
      <batchtest>
         <fileset dir="${path.to.compiled.test.classes}">
            <include name="**/tests/Test*.class" />
         </fileset>
      </batchtest>
   </junit>

   <junit haltonfailure="false">
      <sysproperty key="test.driver" value="org.openqa.selenium.ie.InternetExplorerDriver" />
      <classpath>
         <pathelement location="${path.to.tests.jar}"/>
      </classpath>
      <batchtest>
         <fileset dir="${path.to.compiled.test.classes}">
            <include name="**/tests/Test*.class" />
         </fileset>
      </batchtest>
   </junit>
</target>

Данный таск прогонит все известные тесты из классов, чьи имена начинаются с Test под браузерами Firefox и InternetExplorer. В зависимостях таски с базовой инициализацией, компиляцией и выгрузкой скомпилированных тестов на тестовую площадку.

Фишки-плюшки

Некоторые «браузерные» реализации (Firefox, Opera, Chrome) поддерживают снятие скриншотов. Это может быть полезно дабы зафиксировать визуальное состояние, в котором пребывала тестовая страница в момент, когда тест не прошел. Для этого подойдет функционал JUnit4 – TestWatchman.

@Ignore
abstract public class WISbisTest {

    // Папка для скриншотов
    private String screenshotDir =
            System.getProperty("test.screenshotDir", "");

    @Rule
    public MethodRule watchman = new TestWatchman() {

        /**
         * Будет вызван при каждом "проваленном" тесте
         * @param e Брошенное тестом исключение
         * @param method Тест-метод
         */
        @Override
        public void failed(Throwable e, FrameworkMethod method) {
            if(_driver instanceof TakesScreenshot && !screenshotDir.equals("")) {
                String browserName = _driver.getClass().getName();
                String testSuiteName = method.getMethod().getDeclaringClass().getName();
                browserName =
                        browserName.substring(browserName.lastIndexOf('.') + 1);
                testSuiteName =
                        testSuiteName.substring(testSuiteName.lastIndexOf('.') + 1);

                byte[] screenshot =
                        ((TakesScreenshot)_driver).getScreenshotAs(OutputType.BYTES);
                try {
                    FileOutputStream stream =
                            new FileOutputStream(
                                    new File(
                                        String.format("%s/screenshot_%s_%s_%s.png",
                                                screenshotDir,
                                                browserName,
                                                testSuiteName,
                                                method.getName())));
                    stream.write(screenshot);
                    stream.close();
                } catch (IOException e1) {
                    e1.printStackTrace(System.out);
                }
            }
        }
    };
    // все остальное...

}

Добавим переменную с путем к папке со скриншотами в Ant-билд

   <junit haltonfailure="false">
      <sysproperty key="test.driver" value="org.openqa.selenium.firefox.FirefoxDriver" />
      <sysproperty key="test.screenshotDir" value="${screenshotsDir}" />
      <classpath>
         <pathelement location="${path.to.tests.jar}"/>
      </classpath>
      <batchtest>
         <fileset dir="${path.to.compiled.test.classes}">
            <include name="**/tests/Test*.class" />
         </fileset>
      </batchtest>
   </junit>

Интеграция

В текущей реализации Ant-билд гоняется через Jetbrains TeamCity. Запуск билда настроен на сброс кода в SVN. Интеграционные тесты – часть общей процедуры тестирования. При провале любого из интеграционных тестов снимается скриншот и публикуется как «артефакт» билда – можно видеть не только какие тесты «отъехали» после сброса в транк какого-либо функционала, но и увидеть «как» они «отъехали».

В настоящее время используется тестирование под IE и Firefox, Chrome не подключен по причине некоторых трудностей с интеграцией (судя по всему в ChromeDriver присутствуют некоторые ошибки, не позволяющие нормально искать элементы на странице в некоторых случаях – по состоянию на 2.0b1, сейчас доступна 2.0b2 но работу с ней пока не пробовали)

• есть в виде плагина для применяемой командой IDE – PhpStorm (к сожалению в настоящий момент плагин не работает на текущей платформе PhpStorm, о чем есть соответствующий тикет в статусе Started)
• умеет выполнять тесты сам в нескольких браузерах
• умеет давать отчеты о Code coverage

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

Попробуем в деле

Код, который будем тестировать

var greeter = function(toSay){
  this.whatToSay = toSay;
}

greeter.prototype.say = function(sayBye){
  if(sayBye == true)
    return "Goodbye " + this.whatToSay;
  else
    return "Hello " + this.whatToSay;
}

И тест

var testCase = new TestCase("Say");

testCase.prototype.testCase1 = function(){
  var i = new greeter('test');
  assertEquals("Hello test", i.say(false));
};

Файловая структура

  \jstd
    \plugins
      coverage.jar
    code.js
    test.js
    conf
    jstestdriver.jar

Конфигурация для запуска (файл conf)

load:
 - code.js
 - test.js

server: http://localhost:4224

Запускаем

Сперва стартуем сервер

H:\jstd>java -jar jstestdriver.jar --port 4224

Запускаем браузер, идем на http://localhost:4224, овладеваем браузером. Запускаем прогон тестов.

H:\jstd>java -jar JsTestDriver.jar --config conf --tests all
..
Total 2 tests (Passed: 2; Fails: 0; Errors: 0) (1,00 ms)
  Chrome 6.0.472.63 Windows: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (1,00 ms)
  Safari 525.28.1 Windows: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (1,00 ms)

Видим, что прогнали всего 2 теста. В т.ч. в браузере Chrome – 1, и он прошел успешно, в браузере Safari – также 1 и также успешно. Все замечательно.

А что там было насчет code coverage?

CodeCoverage подключается отдельным плагином. Данные о покрытии могут либо отображаться в виде статической информации (файл такой-то покрыт на N%) по окончании исполнения тестов, либо могут выгружаться в файл формата LCOV. Авторы предлагают генерировать визуальные отчеты с помощью тулзы genhtml. Беглый поиск портированных под Win32 результатов не дал, поднимать Cygwin или отдельную машину для построения отчетов не хочется…

Запустим тесты с code coverage

Подключим плагин. Отредактируем конфигурационный файл (conf).

load:
 - code.js
 - test.js

server: http://localhost:4224

plugin:
 - name: "coverage"
   jar: "plugins/coverage.jar"
   module: "com.google.jstestdriver.coverage.CoverageModule"

Запустим тесты

H:\jstd>java -jar JsTestDriver.jar --config conf --tests all
Safari: Runner reset.
.Safari: Runner reset.
Chrome: Runner reset.
.Chrome: Runner reset.

Total 2 tests (Passed: 2; Fails: 0; Errors: 0) (1,00 ms)
  Chrome 6.0.472.63 Windows: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (1,00 ms)
  Safari 525.28.1 Windows: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (0,00 ms)

H:/jstd/code.js: 83.33333% covered
H:/jstd/test.js: 100.0% covered

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

H:\jstd>java -jar JsTestDriver.jar --config conf --tests all --testOutput ./out
Safari: Runner reset.
.Safari: Runner reset.
Chrome: Runner reset.
.Chrome: Runner reset.

Total 2 tests (Passed: 2; Fails: 0; Errors: 0) (1,00 ms)
  Chrome 6.0.472.63 Windows: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (1,00 ms)
  Safari 525.28.1 Windows: Run 1 tests (Passed: 1; Fails: 0; Errors 0) (1,00 ms)

Теперь информации о покрытии не видно совсем, но в папке ./out появился файл с покрытием в формате LCOV.

Формат LCOV

Формат lcov-файла, генерируемого js-test-driver предельно прост.

SF:H:/jstd/code.js
DA:1,2
DA:2,2
DA:5,2
DA:6,2
DA:7,0
DA:9,2
end_of_record
SF:H:/jstd/test.js
DA:1,2
DA:3,2
DA:4,2
DA:5,2
end_of_record

SF – файл, для которого приводятся данне далее, DA – данные о покрытии (DA:Строка,СколькоРазВыполнена).

Генерируем красивый отчет: PHP_CodeCoverage

PHPUnit – фреймворк дле реализации юнит-тестирования для PHP, имеет возможность генерировать отчеты о code coverage. Модуль, занимающийся CodeCoverage, очень легко отделяем и очень аккуратно реализован. В состав входит интерфейс PHP_CodeCoverage_Driver, классы, имплементирующие его, могут служить источником данных о Code coverage для прочих компонентов проекта (построитель отчетов в т.ч.).

Xdebug. Как он отдает данные о покрытии?

Для файла…

<?php
xdebug_start_code_coverage();

function a() {
    $x = 10;
}

$b = 30;

var_dump(xdebug_get_code_coverage());

Получим результат…

array(
  'Z:\home\test\www\test.php' =>
    array(
      4 => 1
      8 => 1
      10 => 1
    )
);

Видно что форматы очень похожи, можно сделать свой драйвер

Ниже – простой пример кода, генерирующего отчет о покрытии. Предполагается, что данные о покрытии находятся в файле coverage.dat. Отчет будет расположен в папке CodeCoverageReport.

<?php

include('PHP/CodeCoverage.php');
include('PHP/CodeCoverage/Driver/Lcov.php');
include('PHP/CodeCoverage/Report/HTML.php');

// ./lcov_coverage.dat contains ine coverage report in LCOV format

$coverage = new PHP_CodeCoverage(new PHP_CodeCoverage_Driver_Lcov('./coverage.dat'));

$coverage->start('mytest');
$coverage->stop();

$writer = new PHP_CodeCoverage_Report_HTML();
$writer->process($coverage, 'CodeCoverageReport');

Что получается, можно посмотреть здесь. Можно посмотреть на отчет и увидеть, что наш сложный пример не полностью покрыт тестами, пропущена одна ветка и ее надо срочно покрыть тестами.

Спасибо за багрепорт и новый хост проекту http://chelmaps.ru