random technical notes

VSTest.Console.exe should be used from .NET Framework 4.6.1 instead of MSTest.exe to run unit tests from command line.

MSTest.exe brings “No tests to execute” error message.

More info:

• run Visual Studio manage and unmanage unit tests from command line
• Using VSTest.console from the command line
• Running automated tests from the command line

MSTest is used for Managed C#, C++ Tests and Test Execution Command Line Tool (vstest.console.exe) for unmanaged C++ tests.

MSTest example:

>"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\MSTest.exe" /testcontainer:managed_unitTest.dll /testsettings:mysettings.testsettings

Test Execution Command Line Tool example:

>"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" unmanaged_unitTest.dll /Settings:mysettings.testsettings /platform:x86

Additional links:

• Writing Unit tests for C/C++ with the Microsoft Unit Testing Framework for C++
• Verifying Code by Using Unit Tests
• Run Tests in Your Build Process

Unit testing native code with Unit Test Explorer

In Visual Studio, you can create unit tests for unmanaged code written in C++. Unmanaged code is sometimes referred to as native code.

The following procedure contains the essential information that will get you started. The later sections provide a walkthrough that describes the steps in more detail.

patterns & practices – Hilo: dev a Windows Metro style app using C++ & XAML

Hilo guides you though the development of a Windows Metro style app. The Hilo sample is a photo viewing and tagging app using C++ and XAML. Hilo demonstrates how to create live tiles, virtualize scrolling, suspend and resume the app, implement search, share and other contracts.

Verifying Code by Using Unit Tests

The Visual Studio 11 unit test tools are designed to support developers and teams who incorporate unit testing in their software development practices. Unit tests give developers and testers a quick way to look for logic errors in the methods of classes in Visual C#, Visual Basic, and Visual C++ projects.

• ООП (и его реализация на С++) хорошо подходит для неоднородной команды, когда надо создавать ограничения на использование данных (объектов), чтобы более слабые программисты не натворили больших бед.
• бездумное использование выделения памяти (операторы new/delete) и умных указателей – показатель не очень хорошей архитектуры. Если в API функции сказано, что надо за собой удалять объект (структуру), так будь любезен не ленись, а то напридумали всякие «помойки памяти» (garbage collection) для ленивых.
  • использование «умных указателей» может быть накладным: Smart Pointer Timings.  При этом класс «умный указатель» должен переопределить многие операторы (например, operator*(), operator=() и так далее) и тогда простая операция на самом деле будет не такой простой:
    smart1->setValue(smart2->getValue());
    При этом всё-таки надо проверять на наличие объекта (if(true == smart1.healthy())), так как возможна ситуация, когда кто-нибудь напишет так: smart1= NULL;
  • уж лучше использовать идею заложенную в IUnknown интерфейсе, когда для подсчёта ссылок используются явно вызываемые методы AddRef() и Release() (конструктор и деструктор у такого класса объявлены защищёнными, что предотвращает неправильный вызов операторов new/delete для этого класса)
  • бездумное объявление виртуальных функций тоже добавляет дополнительные расходы на доступ к методам класса. Смотри презентацию “Virtual Functions“. Для уменьшения накладных расходов, Microsoft даже добавила специальный атрибут при объявлении интерфейсов: __declspec(novtable).
• При декларации класса на языке C++ необходимо помнить о правиле «большая тройка».
  • При этом не очень подготовленные программисты забывают, что хоть класс состоит из методов и данных, но всё-таки это отдельные сущности и при создании класса память выделяется только для данных.
• как минимум «простые» приложения можно описать используя парадигму конечного автомата (state machine) – есть состояние программы, которое можно узнать проверяя значения переменных через функции и есть переходы от одного состояния в другое, при этом тип состояния можно легко узнать.
• Графический интерфейс пользователя вообще неправильно разрабатывать используя объекты. Есть примитивы (могут быть и свои контролы). Есть состояния этих примитивов и переходы. Но в навороченных приложениях создают такую объектную модель, что два соседних контрола не могут взаимодействовать друг с другом напрямую и всё взаимодействие идёт через уровень логики.
  • как вариант, Qt версии 4.6 реализован State Machine Framework.
• Даже временные данные можно хранить в SQLite (надо проверить быстродействие) и тогда доступ к данным может быть осуществлён глобально, нет проблем с многопоточностью так как SQLite потокобезопасен и при этом сериализация может быть достигнута довольно простой операцией сохранения таблицы в файл.
• Исключения ещё хуже чем бездумное выделение памяти – стэк забивают (так как нужно обрабатывать раскрутку исключения), а так же нарушают логику работы.
• Про мультипоточное программирование вообще молчу. Для многих это сложно.

CppUnit is a C++ unit testing framework. It started its life as a port of JUnit to C++ by Michael Feathers. For a quick tour of unit testing with CppUnit, see the Cookbook in the latest documentation. For an introduction to unit testing, see UnitTest, ProgrammerTest, and CodeUnitTestFirst.

Features:

• XML output with hooks for additional data (XSL format avaliable in release 1.10.2 needs some FiXing)
• Compiler-like text output to integrate with an IDE
• Helper macros for easier test suite declaration
• Hierarchical test fixture support
• Test registry to reduce recompilation need
• Test plug-in for faster compile/test cycle (self testable dynamic library)
• Protector to encapsulate test execution (allow capture of exception not derived from std::exception)
• MfcTestRunner
• QtTestRunner, a Qt based graphic test runner

This page is a list of tables of code-driven unit testing frameworks for various programming languages. Some but not all of these are based on xUnit.

UnitTest++ is a lightweight unit testing framework for C++.

It was designed to do test-driven development on a wide variety of platforms. Simplicity, portability, speed, and small footprint are all very important aspects of UnitTest++.

UnitTest++ is ANSI portable C++ and makes minimal use of advanced library and languages features, which means it should be easily portable to just about any platform. Out of the box, the following platforms are supported:

• Win32
• Linux
• Mac OS X

WinUnit offers a unique approach to unit testing native (C/C++) code on Windows.

WinUnit was originally introduced in the article “Simplified Unit Testing for Native C Applications” by Maria Blees in the February 2008 issue of MSDN Magazine. Click here to read the article and learn more about WinUnit.

Features:

• One executable which runs tests in separate DLLs
• One header file to make writing tests easier
• Logger extensibility
• Easy to automate
• Macros for use in Visual Studio