Но дело не в этом. Искал иформацию о куске говна, а нашел бриллиант. Отличная, замечательная презентация о юнит-тестах.  Здесь.

ППКС.

БОльшая половина кода нашего проекта на первый взгляд выглядит очень хардкорно. Если опустить пару моментов, где я вдоволь оттянулся с белой и черной шаблонной магией, то бросится в глаза, что остальная часть этой половины идет вразрез с заветами секты “ООП”  и ее течения “многоэтажные иерархии классов” (да, я редко сажаю леса вроде приведенного на картинке ниже). В глаза бросится, да не долетит, а упадет и стечет (может быть даже прямо в ботинки).

При ближайшем рассмотрении код оказывается простым как пробка, понятным как дважды два и гибким, как резинка от трусов. Что-то нужно изменить? Нет проблем. Изволите перламутровые пуговицы вместо молнии? Пожалуйста. Что? Хотите декоративные пуговицы, а ширинку все же на молнии? Проще простого. И так далее. Причем для проведения хирургической операции по пересадки молнии не приходится укорачивать рукава и заодно перестраивать ещё и платяной шкаф, как это часто случается в индустрии программного обеспечения. Кстати, перекраска последнего по желанию заказчика (любой каприз за Ваши деньги!) тоже вовсе не изменяет цвет костюмов, в нем висящих. Код-как детали из детского конструктора, строй из них все, что хочешь.

Другая, хоть и меньшая, но не менее важная половина кода – полная противоположность всему вышесказанному. Вроде изящная структура интерфейсов и классов отлично видна даже в перевернутый бинокль (смотри картинку выше), но стоит посмотреть невооруженным глазом, как уши сами, опасаясь неминуемых последствий, начинают инстинктивно сворачиваться в трубочку.  Местами этот спагетти-код настолько суров, что если потянуть за макаронину в своей тарелке, мясные тефтельки в тарелке у клиента воооон за тем столиком придут в движение и начнут водить хороводы. Если сравнить с более материальным миром, то попытка что-нибудь исправить в таком коде напоминает процесс штопания дырки в носке, который по непонятной причине неизменно заканчивается пришитым к ширинке рукавом майки (откуда у майки взялся рукав, лучше даже и не спрашивать, я давно забросил все попытки выяснить это). Причем после отпарывания рукава от ширинки обнаруживается, что до сих пор бывшими модельными ботинки каким-то образом превратились в ласты 47 размера, а стильные солнечные очки – в маску сварщика.

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

Самое замечательное во всей этой истории то, что разница между кодом, который лучше не трогать и кодом, с которым очень легко делать все, что угодно, очень уж очевидна. Порой кажется, что кто-то где-то провел границу в коде и сказал “с этого момента прекращаем гнать лажу по-старому и начинаем по-новому”.

Это мой первый проект  за последние несколько лет, где практика юнит-тестирования и частично TTD были внедрены ровно на полпути. В моей практике это первый случай, где преимущества правильного использования юнит-тестирования не просто говорят сами за себя, а буквально кричат изо всех окон Студии, попутно постукивая шарахающихся зевак деревянной киянкой по голове.

Итак, большая половина кода в проекте была написана после внедрения технологии юнит-тестирования. Поначалу произведя эффект разорвавшейся клизмы, что всегда бывает в компаниях, где думают, что юнит-тесты – это исключительно средство тестирования кода (что есть неправда – это в первую очередь технология разработки), результат внедрения техники превзошел экономический эффект от использования технологии “сборка трезвым” на предприятии по производству яиц Фаберже с часовым механизмом. Не буду говорить о том, что подавляющее большинство найденных багов относится как раз к старой половине, при написании которой, похоже, руководствовались принципом “некогда фигней разной и тестами в частности заниматься, копать надо”, это мелочи. Тесты совсем не панацея от багов, хотя и помогают асимптотически устремить их число к нулю.

На самом деле, основной эффект от использования тестов проявился сейчас, спустя почти полгода после окончания разработки. Проект уже вышел и находится в стадии исправления и добавления фич. Ну, вы понимаете, стоит заказчику получить то, что он, собственно и заказывал, так начинается “а почему это работает так, а не эдак? Да, мы думали, что оно будет работать именно так, почему вы нам не сказали, ой, разве сказали, а когда, ой, в спеке написано, так мы ж его не читали, а почему вы нам не сказали, что его нужно читать, но все равно, сделайте нам ништяк, да так, чтобы нам ничего за это не было”. Так вот, если исправление или новая фича затрагивает новый код, то никаких проблем – из самого кода очевидно, что, где и как нужно изменить, а полтысячи разных тестов добавляют уверенности в том, что система не пойдет на йух после добавления новой фичи в ядро.

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

Впрочем, это довольно типичная ситуация. Разработчики потратили время, кофе и пончики, разрабатывая и согласовывая интерфейсы и то, что называется “Top level architecture”, и придумали действительно очень красивую архитектуру. Но как только принялись собственно за кодирование, напрочь забыли о том, что собственно дизайн модулей, интерфейсы реализующих, тоже хорошо бы придумать и потом поддерживать. Дальнейшая разработка напоминает скорее постройку забора бойцами Советской Армии. Бери больше, кидай дальше, пока летит – отдыхай.

Когда разработка ведется с использованием юнит-тестирования, разработчик стремится написать тест для любой маленькой фигни. Это накладывает серьезнейший отпечаток на дизайн модуля, так как код в должен быть тестируемый в первую очередь. Значит, прежде чем бросаться грудью на амбразуры, програмиист должен подумать, а как, собственно, он собирается проверить, что этот кусок кода работает именно так, как задумано. А так как программист это существо, мозговой деятельности обученное,  тут и начинаются интересные вещи. Первыми исчезают монстроидальные классы вида “универсальный всемогутор” с названием “менеджер чего-то там” и иже с ними, вместо этого появляется десяток-другой классов поменьше или вообще функций, каждая из которых решает какую-то отдельную небольшую задачу, не заморачиваясь о существовании других классов, функций и типов данных, ей неинтересных. Соответственно, твердое “нет” говорится процессам, где состояние объекта меняется неявно и незаметно. Функции, в которые раньше передавались огромные структуры для работы лишь с одним из их полей, начинают принимать только то самое поле. Внутренние и неявные связи исчезют на глазах. В следующий момент обнаруживается, что многие из мелких функций и классов теперь можно и нужно использовать в других местах проекта. Потом, при написании теста для отдельного класса обнаруживается, что для его удобного использования нужно применить Inversion of control, что и будет вскоре сделано, заодно решив еще целую кучу намечающихся проблем.

Короче говоря, цель юнит-тестирования – помочь программисту начать выступать не только и не столько в роли творца шедевра, но первым и самым главным пользователем и критиком своего же кода.  “Плохой” код, то есть код, который трудно стыковать с другими модулями, очень сложно, а то и вообще невозможно тестировать, в то время как код, для которого написан и выполняется тест, гарантирует как минимум, что он стыкуется с другим относительно простым кодом – кодом теста – и его уже точно один раз (а может и больше) использовали и проверили в деле. Это помогает программисту увидеть слабости кода и изолировать потенциальные проблемы интеграции задолго до того, как потенциальные проблемы превратятся в проблемы реальные.

This is easy to understand – while there is nothing wrong in static variable, even in global static variable, we must ensure that it is initialized before it is used first, which is especially important if the object has to be created dynamically. And this is the problem Singleton pattern solves.

Take the example

// SomeSourceFile.h
#include "CoffeePlantation.h"
static CoffeePlantation g_Plantation;

// SomeSourceFile.cpp
#include "SomeSourceFile.h"
// Initialize the instance
g_Plantation = CoffeePlantation();

Note – coffee plantation object is created on a stack. Plantation’s constructor will be called before main() and, presumably, any other code that uses g_Plantation. But in order to use this single plantation, you’ll must include this “SomeSourceFile.h” into every file when it is or may be referred from. Moreover, once you added more global statics, you may get lost is you sources as you’ll need to keep in mind which header declares what variable. Having single common header file may help a little, though, but not always.

From the other hand, there are still heaps of cases when you’d rather use global static variable for certain need. For instance, pattern “State” (see “Design patterns” by GoF) assumes that all object represent states have to implement singleton pattern. But at the closer look you may realize that it makes code unnecessary complex and bulky – state machine of that kind assumes that all transitions and states are already known, they don’t change in runtime and can be created once-and-for-all, in other words, they must be static.

Right, how we handle this situation then?

Well, it’s about the time when “template” word, so many developers are still afraid of, should be addressed. C++ template is a great way to ask compiler to generate as many synthetic data types as we want exactly when we need them. For instance, vector<char> and vector<unsigned char> are two different data types. Which meaning does it have for our task?

Check this out:

// file name: StaticInstance.htemplate <class T>
class  tStaticInstance
{
public:
        static T* GetInstance();
private:
        static T m_Instance;
}

template <class T>
T tStaticInstance<T>::m_Instance = T();

That’s it. That’s really all we need to hide ugly global static behind nice looking fence. Now, instead of declaring static variable in designated header and then pushing it *.h around the project, just do this:

#include "StaticInstance.h"/// somewhere somewhentStaticInstance<MyConcreteType>::GetInstance()->SomeMethod();

tStaticInstance<OtherType>::GetInstance()->SomeMethod();

This code may look a bit scary, but it solves the whole bunch of problems:

• There is no need to modify either of MyConcreteType or OtherType to implement singleton functionality they may not need generally.
• Global static variable can be “created” from any place in your program without the need of declaring it anywhere else
• Does not have singleton’s weaknesses
• This expression clearly explains that in this particular place we wanted to deal with single global instance of the class. There are quite a few cases when it may be useful
• Code is very simple
• Static objects are created automatically and only if they are used. Unlike the case with implicit static declaration, it is now impossible to declare an object that is never used.

Of course, there is a price to pay:

• The uniqueness of the instance is only guaranteed within single binary and we fully rely on modern compiler and linker
• Object gets created once a construction with tStaticInstance::GetInstance() appears in the code, even if that code is never going to be used (which is quite bad by itself) or gets called once in a blue moon.

It is also not idiot-proof:

MyType pInstance* = tStaticInstance<MyConcreteType>::GetInstance();

delete pInstance;     // Something bad happens here

That delete will lead to crash, but it will be trivial to track down and fix. You write unit test for you code, aren’t you?

I have been using this pattern in several projects and it works just fine, assuming that it is intended for occasions where your code is allowed to know that is deals with static instance of the class.

Having said that, this is how I would deal with my coffee plantation:

// CoffeeHarvester.h
#include "CoffeePlantation.h"
#include "StaticInstance.h"
// ...
tStaticInstance<CoffeePlantation>::GetInstance()->CheckIfCoffeeRipeEnough();