Вторник, 23.04.2024, 20:59 Приветствую Вас Гость

Quick Soft

Главная | Мой профиль | Форум | Загрузки | RSS | Выход | 

Quick Unit

Асинхронное модульное тестирование.

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

Хочется еще указать на тот факт, что лично мне довелось увидеть только одну реализацию асинхронного тестирования и то, только для Silverlight 3. 

Пример асинхронного теста на Silverlight
  1.     [TestClass]
  2.     public class IGActiveDirectory_test : SilverlightTest
  3.     {
  4.         [TestMethod]
  5.         [Asynchronous]//указываем что тест асинхронный
  6.         public void test_AsyncExample()
  7.         {
  8.             //в фоновом потоке выполняем длительную операцию
  9.             Thread cThread =
  10.                 new Thread( delegate()
  11.                                 {
  12.                                     //какая-то длительная опреация
  13.  
  14.                                     //указываем что тест пройден!
  15.                                     EnqueueTestComplete();
  16.                                 } );
  17.             cThread.Start();
  18.         }
  19.     }

Конечно я не занимался масштабными поисками, но беглый осмотр показал, что ничего подобного, кроме как для Silvrlight к сожалению нет, ни для .net Framework нет, ни для native C++. А всякие хитрые решения с блокировками, запусками в фоновых потоках не в счет. Это только усложняет и затягивает процесс тестирования.

И так предлагаемый вашему вниманию инструмент называется QuickUnit, это наш внутренний продукт, о котором хочется рассказать и поделиться, не только бинарниками, но и исходниками. Он реализован пока только на языке C++ при помощи библиотеки QT. Почему QT, да потому что её реализация системы метаданных, как нельзя лучше подходит для решения задачи асинхронного тестирования (она мне очень напоминает рефлексию в .net). В будущем планируется реализация для платформ .net и mono.

Представим себе, что нам необходимо написать модульный тест для класса, выполняющего операции в фоновом потоке. Для примера напишем маленький тест для метода QWebView::load( ... );, так как результат выполнения данной функции мы получим только через обработку сигнала loadFinished( bool ), Для сравнения сначала напишем "асинхронный" тест с помощью CPPUNIT, а затем с помощью QuickUnit и сравним полученный результат.

И так перед нами тестовый класс, реализованный с помощью CPPUNIT:

Пример тестирования асинхронного метода с помощью CPPUNIT
  1. #ifndef CWEBVIEWTEST_H
  2. #define CWEBVIEWTEST_H
  3.  
  4. class CWebViewTest : public QObject,
  5.                      public CPPUNIT_NS::TestFixture
  6. {
  7.     Q_OBJECT
  8.  
  9. public:
  10.  
  11.     CWebViewTest( QObject *parent = 0 );
  12.     ~CWebViewTest();
  13.  
  14.     CPPUNIT_TEST_SUITE( CWebViewTest );
  15.         CPPUNIT_TEST( test_WebView_Load );
  16.     CPPUNIT_TEST_SUITE_END();
  17.  
  18.  
  19.  
  20. public:
  21.  
  22.     //подготовка теста
  23.     virtual void setUp()
  24.     {
  25.         m_bPassed = false;
  26.         m_pView = new QWebView( 0 );
  27.     };
  28.  
  29.     //наводим порядок после прохождения теста
  30.     virtual void tearDown()
  31.     {
  32.         delete m_pView;
  33.     };
  34.  
  35.  
  36.  
  37. private:
  38.  
  39.     //тестируемый объект
  40.     QWebView * m_pView;
  41.  
  42.     //уведомление о завершении теста
  43.     bool m_bPassed;
  44.         
  45.  
  46.  
  47. private:
  48.  
  49.     //тест асинхронного метода
  50.     void test_WebView_Load()
  51.     {
  52.         connect( m_pView,
  53.                  SIGNAL( loadFinished( bool ) ),
  54.                  SLOT( slot_load_finished( bool ) ) );
  55.  
  56.         m_pView->load( QUrl("http://www.google.ru") );
  57.  
  58.         /* здесь встает проблема преждевременного завершения теста,
  59.         необходимо удержать исполняющий поток до момента получения сигнала loadFinished( bool )
  60.         */
  61.  
  62.         while ( !m_bPassed ) //один из вариантов удержания (однако излишняя нагрузка на ЦП)
  63.         {
  64.             QApplication::processEvents( QEventLoop::ExcludeUserInputEvents );
  65.         }
  66.         
  67.     }
  68.  
  69.  
  70. private slots:
  71.  
  72.     void slot_load_finished( bool bOk )
  73.     {
  74.         CPPUNIT_ASSERT(bOk);
  75.         CPPUNIT_ASSERT( m_pView->page()->totalBytes() > 100 );
  76.  
  77.         m_bPassed = true;
  78.     }
  79.     
  80. };
  81.  
  82. #endif // CWEBVIEWTEST_H

Главная проблема, это удержать исполняющий поток в тестовой функции, до того момента пока не будет полностью обработан сигнал loadFinished( bool ) в слоте slot_load_finished( bool bOk ) , и только затем поток можно будет пускать далее. Если не удерживать поток, то по сути тест нельзя считать правильным, так как он с большой долей вероятности завершится преждевременно.  Самый простой вариант удержания исполняющего потока, это принудительная обработка сообщений в очереди: 

  1. while ( !m_bPassed ) //один из вариантов удержания (однако излишняя нагрузка на ЦП)
  2. {
  3.     QApplication::processEvents( QEventLoop::ExcludeUserInputEvents );
  4. }

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

Теперь рассмотрим предлагаемое нами решение для таких случаев:

Пример асинхронного модульного тестирования
  1. #ifndef ASYNCHRONOUS_TEST_EXAMPLE_H
  2. #define ASYNCHRONOUS_TEST_EXAMPLE_H
  3.  
  4. #include <QS_QuickUnit.h>
  5. #include <QtWebKit\QtWebKit>
  6.  
  7. class AsynchronousTestExample : public QS_TestClass
  8. {
  9.     Q_OBJECT
  10.  
  11. private:

  13.     QWebView * m_pView;
  14.  


  17. private slots:
  18.  
  19.     //тестовый слот
  20.     void test_LoadWebPage()
  21.     {
  22.         QS_BEGIN_TEST;
  23.  
  24.         m_pView = new QWebView( 0 );
  25.  
  26.         connect( m_pView,
  27.             SIGNAL( loadFinished( bool ) ),
  28.             SLOT( slot_loadFinished( bool ) ) );
  29.  
  30.         m_pView->load( QUrl( "http://custom.site.com" ) );
  31.  
  32.         QS_END_TEST;
  33.     }//по выходу из функции тест не завершается, поток держать уже не надо!


  36.  
  37.     //посторонний слот (система его вызывать не будет, 
  38.     //так как он не имеет приставки test_)
  39.     void slot_loadFinished ( bool ok )
  40.     {
  41.         QS_BEGIN_TEST;
  42.  
  43.         //проверяем результат
  44.         QS_IS_TRUE( ok );
  45.         QS_IS_TRUE( m_pView->page()->totalBytes() > 100 );
  46.  
  47.         QS_END_TEST;
  48.         QS_TEST_COMPLETE;//Указываем, что тест завершен успешно
  49.     }
  50. };
  51.  
  52. #endif //ASYNCHRONOUS_TEST_EXAMPLE_H

Как видно из примера декларативная часть тестового класса минимальна. Проблема удержания исчезла, код стал компактнее и проще. Правда возникает другая, если разработчик забудет указать, что тест надо завершать, система будет ждать вечно (в планы у нас входит timeout для таких случаев, что бы не тормозить процесс тестирования в целом) команды на завершение. И конечно главное отличие от CPPUNIT и других решений это привязка к QT, т.е. перед использованием QuickUnit необходимо сначала установить QT. Хотя на наш взгляд это не так уж и много, для упрощения тестирования асинхронных операций. Процесс установки описан в руководстве разработчика.

Кратко рассмотрим основные возможности QuickUnit.

Сам тестовый класс должен быть наследником QS_TestClass и быть так же классом QT ( объявляется макрос Q_OBJECT ). Для отделения тестовых слотов от посторонних, первые имеют приставку test_. Все тестовые слоты выполняются в контексте основного потока, что позволяет использовать GUI классы, COM объекты, одним словом все те классы, которые могут быть созданы только в контексте основного потока приложения. 

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

Тестовые слоты имеют набор атрибутов. Задача атрибута – указать системе, что слот должен выполняться с некоторыми особенностями. Для минимизации на декларирование, атрибуты включаются в наименование самого тестового слота, к примеру:

Пример использования атрибутов
  1. #ifndef ATTRIBUTE_USAGE_EXAMPLE_H
  2. #define ATTRIBUTE_USAGE_EXAMPLE_H
  3.  
  4. #include <QS_QuickUnit.h>
  5.  
  6. class AttributeUsageExample : public QS_TestClass
  7. {
  8.     Q_OBJECT
  9.  
  10.         private slots:
  11.  
  12.             void test_myTest_Fatal()
  13.             {
  14.                 QS_BEGIN_TEST;
  15.  
  16.                 //реализуем логику тестирования
  17.  
  18.                 QS_END_TEST;
  19.                 QS_TEST_COMPLETE;
  20.             }
  21.  
  22.             void test_myTest_Repeat_15()
  23.             {
  24.                 QS_BEGIN_TEST;
  25.  
  26.                 //реализуем логику тестирования
  27.  
  28.                 QS_END_TEST;
  29.                 QS_TEST_COMPLETE;
  30.             }
  31.  
  32.             void test_myTest_Fatal_Repeat_15()
  33.             {
  34.                 QS_BEGIN_TEST;
  35.  
  36.                 //реализуем логику тестирования
  37.  
  38.                 QS_END_TEST;
  39.                 QS_TEST_COMPLETE;
  40.             }
  41. };
  42.  
  43. #endif //ATTRIBUTE_USAGE_EXAMPLE_H

В текущей версии реализовано пока только два атрибута _Fatal и _Repeat_N. Первый указывает, что слот является критическим, а второй указывает, что слот надо повторно взывать N раз подряд. По умолчанию тестовый слот не критичен и выполняется только один раз. Макросы QS_BEGIN_TEST и QS_END_TEST это блок try catch в случае перехвата исключения тестовый слот будет прерван, и зафиксирован, как не прошедший проверку. Так же имеется группа проверочных макросов с ними можно ознакомиться в руководстве разработчика. После описания тестового класса его остается только зарегистрировать. Регистрацию рекомендуется реализовывать в main.cpp

Quick Unit подходит не только для тестирования под QT, но так же полностью совместим с WIN32, ATL, MFC.По результатам тестирования в консоль выводится отчет о пройденных тестах, с указанием причин и точек возникновения ошибок, в отчет так же включено время выполнения тестового слота, класса. 

Мы искренне надеемся, что QuickUnit поможет в решении ваших задач. Все предложения и замечания можно и нужно оставлять здесь.
Категории раздела
QuickUnit [1]
Новости об изменениях в библиотеке QuickUnit
Архив записей
Наш опрос
Помогает ли проект QuickUnit Вам в решении ваших задач модульного тестирования
Результаты | Архив опросов
Всего ответов: 4
Статистика
Онлайн всего: 1
Гостей: 1
Пользователей: 0
Copyright Quick Soft © 2011
Бесплатный конструктор сайтов - uCoz