Меню сайта

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

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

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

В качестве вступления хочется заметить, что лично мне довелось увидеть только одну реализацию библиотеки асинхронного тестирования и то, только для Silverlight 3 и 4 (из пакета Silverlight Toolkit).

 [TestClass]public class MyTest_test : SilverlightTest{[TestMethod][Asynchronous]//указываем что тест асинхронныйpublic void test_AsyncExample(){//в фоновом потоке выполняем длительную операциюThread cThread =new Thread( delegate(){//какая-то длительная опреация//указываем что тест пройден!<-b>-EnqueueTestComplete()-<-/b>-} )-cThread.Start()-}}

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

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

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

Рассмотрим тестовый класс, реализованный с помощью CPPUNIT:
#ifndef CWEBVIEWTEST_H#define CWEBVIEWTEST_Hclass CWebViewTest : public QObject,public CPPUNIT_NS::TestFixture{Q_OBJECTpublic:CWebViewTest( QObject *parent = 0 )-~CWebViewTest()-CPPUNIT_TEST_SUITE( CWebViewTest )-CPPUNIT_TEST( test_WebView_Load )-CPPUNIT_TEST_SUITE_END()-public://подготовка тестаvirtual void setUp(){m_bPassed = false-m_pView = new QWebView( 0 )-}-//наводим порядок после прохождения тестаvirtual void tearDown(){delete m_pView-}-private://тестируемый объектQWebView * m_pView-//уведомление о завершении тестаbool m_bPassed-private://тест асинхронного методаvoid test_WebView_Load(){connect( m_pView,SIGNAL( loadFinished( bool ) ),SLOT( slot_load_finished( bool ) ) )-m_pView->-load( QUrl("http://www.google.ru") )-/* здесь встает проблема преждевременного завершения теста,необходимо удержать исполняющий потокдо момента получения сигнала loadFinished( bool )*///один из вариантов удержания (однако излишняя нагрузка на ЦП)while ( !m_bPassed ){QApplication::processEvents( QEventLoop::ExcludeUserInputEvents )-}}private slots:void slot_load_finished( bool bOk ){CPPUNIT_ASSERT(bOk)-CPPUNIT_ASSERT( m_pView->-page()->-totalBytes() >- 100 )-m_bPassed = true-//сообщаем о завершении}}-#endif // CWEBVIEWTEST_H

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

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

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

Теперь рассмотрим туже задачу, но с использованием QuickUnit:
#ifndef ASYNCHRONOUS_TEST_EXAMPLE_H#define ASYNCHRONOUS_TEST_EXAMPLE_H#include <-QS_QuickUnit.h>-#include <-QtWebKit\-QtWebKit>-class AsynchronousTestExample : public QS_TestClass{Q_OBJECTprivate:QWebView * m_pView-private slots://тестовый слотvoid test_LoadWebPage(){QS_BEGIN_TEST-m_pView = new QWebView( 0 )-connect( m_pView,SIGNAL( loadFinished( bool ) ),SLOT( slot_loadFinished( bool ) ) )-m_pView->-load( QUrl( "http://custom.site.com" ) )-QS_END_TEST-}//по выходу из функции тест не завершается, поток держать уже не надо!//посторонний слот (система его вызывать не будет, //так как он не имеет приставки test_)void slot_loadFinished ( bool ok ){QS_BEGIN_TEST-//проверяем результатQS_IS_TRUE( ok )-QS_IS_TRUE( m_pView->-page()->-totalBytes() >- 100 )-QS_END_TEST-QS_TEST_COMPLETE-//Указываем, что тест завершен успешно}}-#endif //ASYNCHRONOUS_TEST_EXAMPLE_H

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

  1. Если разработчик забудет указать, что тест надо завершать, система будет ждать вечно (в планы у нас входит timeout для таких случаев, что бы не тормозить процесс тестирования в целом) команды на завершение-
  2. Данная библиотека реализована на QT, т.е. перед использованием QuickUnit необходимо сначала установить QT, и если вы используете Visual Studio то и аддон для студии.

Подведем итоги:

что мы приобретаем если используем QuickUnit:

  1. Нет нужды ломать голову, как удержать поток в тестовой функции-
  2. Минимальная декларативная часть тестового класса-
  3. Гибкость при построении тестов, для комплексного тестирования много поточных блоков кода-
  4. Малый размер библиотеки-
  5. Кросс-платформенность.

Недостатки:

  1. Привязка к QT-
  2. Внимательно писать тесты, не забывать о завершении.
Категория: Программирование | Дата: 15.05.13

Меню раздела
Блок