модульное тестирование с ++. как протестировать приватных пользователей?

<p>я хотел бы сделать модульные тесты для моего приложения c++.</p><p>какова правильная форма для тестирования частных членов класса? создать класс друга, который будет проверять приватные члены, использовать производный класс или какой-то другой трюк?</p><p>какую технику используют api тестирования?</p>

<p>обычно проверяется только открытый интерфейс, как обсуждалось в комментариях к вопросу. </p><p>однако бывают случаи, когда полезно тестировать частные или защищенные методы. например, реализация может иметь некоторые нетривиальные сложности, которые скрыты от пользователей и которые могут быть более точно протестированы с доступом к непубличным членам. часто лучше найти способ устранить эту сложность или выяснить, как обнародовать соответствующие части, но не всегда.</p><p>один из способов разрешить юнит-тестам доступ к закрытым членам - через конструкцию <a href="http://www.cplusplus.com/doc/tutorial/inheritance/">friend</a> .</p>

<p>ответ на этот вопрос касается многих других тем. помимо религиозности в cleancode, tdd и других:</p><p>есть несколько способов получить доступ к частным пользователям. в любом случае вы должны отменить проверенный код! это возможно на обоих уровнях синтаксического анализа c++ (препроцессор и сам язык):</p><p><strong> определить все для общественности </strong></p><p>используя препроцессор, вы можете нарушить инкапсуляцию.</p><pre><code>#define private public #define protected public #define class struct </code></pre><p>недостаток в том, что<strong> класс доставляемого кода отличается от класса в тесте </strong>! стандарт c++ в главе 9.2.13 гласит:</p><blockquote> <p>порядок размещения нестатических данных элементов с различными контроль доступа не указан.</p> </blockquote><p>это означает, что компилятор имеет право переупорядочивать переменные-члены и виртуальные функции для теста. вы можете бороться, что это не повредит вашим классам, если не произойдет переполнения буфера, но это означает, что вы не будете тестировать тот же код, что и доставленный. это означает, что если вы обращаетесь к членам объекта, который был инициализирован кодом, скомпилированным с <code>private</code>, не определенным как <code>public</code>, смещение вашего члена может отличаться!</p><p><strong> друзья </strong></p><p>этот метод должен изменить тестируемый класс, чтобы подружить его с тестовым классом или тестовой функцией. некоторые тестовые среды, такие как gtest (<code>friend\_test(..);</code>), имеют специальные функции для поддержки этого способа доступа к личным вещам.</p><pre><code>class x { private: friend class test\_x; }; </code></pre><p>он открывает класс только для теста и не открывает мир, но вы должны изменить код, который будет доставлен. на мой взгляд, это плохо, потому что тест никогда не должен менять проверенный код. в качестве еще одного недостатка это дает другим классам поставляемого кода возможность нарушить ваш класс, называя себя тестовым классом (это также повредит правилу odr стандарта c++).</p><p><strong> объявление личных вещей, защищенных и производных от класса для испытаний </strong></p><p>не очень элегантный способ, очень навязчивый, но работает также:</p><pre><code>class x { protected: int myprivate; }; class test\_x: public x { // now you can access the myprivate member. }; </code></pre><p><strong> любой другой способ с макросами </strong></p><p>работает, но имеет те же недостатки по стандартному соответствию, что и первый способ. например.:</p><pre><code>class x { #ifndef unittest private: #endif }; </code></pre><p>я думаю, что последние оба способа не являются альтернативами первым двум, потому что они не имеют преимуществ перед первыми, но более навязчивы в тестируемом коде. первый способ очень рискованный, поэтому вы можете использовать дружеский подход.</p><hr><p>несколько слов о дискуссии "никогда не проверяй-приват-вещи". одним из положительных моментов модульного тестирования является то, что вы очень рано достигнете точки, когда вам придется улучшать дизайн своего кода. это также иногда является одним из недостатков модульного тестирования. это иногда делает объектную ориентацию более сложной, чем должна быть. особенно, если вы следуете правилу, проектируя классы таким же образом, как и объекты реального мира.</p><p>тогда вам придется иногда менять код на что-то уродливое, потому что подход модульного тестирования заставляет вас делать это. работа на сложных платформах, которые используются для управления физическими процессами, является одним из примеров. там вы хотите отобразить код на физический процесс, потому что часто части процесса уже очень сложны. список зависимостей от этих процессов иногда бывает очень длинным. это один из возможных моментов, когда тестирование частных пользователей становится приятным. вы должны найти компромисс с преимуществами и недостатками каждого подхода.</p><p>занятия становятся иногда сложными! затем вы должны решить разделить их или принять их такими, какие они есть. иногда второе решение имеет больше смысла. в конце концов, это всегда вопрос, каких целей вы хотите достичь (например, идеальный дизайн, быстрое время внедрения, низкие затраты на разработку ...).</p><hr><p><strong> мое мнение </strong></p><p>мой процесс принятия решения о доступе к закрытым членам выглядит следующим образом:</p><ol> <li>вам нужно самим тестировать частных пользователей? (часто это уменьшает общее количество необходимых тестов)</li> <li>если да, видите ли вы какое-либо преимущество в дизайне для рефакторинга класса?</li> <li>если нет, подружитесь с тестом в своем классе (используйте его из-за отсутствующих альтернатив).</li> </ol><p>мне не нравится подход дружбы, потому что он изменяет протестированный код, но риск протестировать что-то, что может не совпадать с поставленным (как это возможно при первом подходе), не оправдывает более чистый код.</p><p>кстати, тестирование только публичного интерфейса - это тоже свободное дело, потому что, по моему опыту, оно меняется так же часто, как и частная реализация. таким образом, у вас нет никакого преимущества, чтобы уменьшить тест на публичных участников.</p>

<p>я сам не нашел золотого решения, но вы можете использовать <code>friend</code> для тестирования приватных членов, если вы знаете, как среда тестирования называет ее методы. я использую следующее для тестирования частных пользователей с помощью теста google. хотя это работает довольно хорошо, заметьте, что это хак, и я не использую его в рабочем коде.</p><p>в заголовке кода, который я хочу протестировать (stylesheet.h), у меня есть:</p><pre><code>#ifndef test\_friends #define test\_friends #endif class stylesheet { test\_friends; public: // ... private: // ... }; </code></pre><p>и в тесте у меня есть:</p><pre><code>#include <gtest/gtest.h> #define test\_friends \ friend class stylesheettest\_parsesingleclause\_test; \ friend class stylesheettest\_parsemultipleclauses\_test; #include "stylesheet.h" test(stylesheettest, parsesingleclause) { // can use private members of class stylesheet here. } </code></pre><p>вы всегда добавляете новую строку в test\_friends, если добавляете новый тест, который обращается к закрытым членам. преимущества этого метода в том, что он довольно ненавязчив в тестируемом коде, так как вы добавляете только несколько #defines, которые не действуют, когда не тестируются. недостатком является то, что это немного многословно в тестах.</p><p>теперь одно слово о том, почему вы хотели бы сделать это. в идеале, конечно, у вас есть небольшие классы с четко определенными обязанностями, а классы имеют легко тестируемые интерфейсы. однако на практике это не всегда легко. если вы пишете библиотеку, то, что <code>private</code> и <code>public</code> продиктовано тем, что вы хотите, чтобы потребитель библиотеки мог использовать (ваш публичный api), а не тем, что нуждается в тестировании или нет. у вас могут быть инварианты, которые вряд ли изменятся и должны быть протестированы, но не представляют интереса для потребителя вашего api. тогда «черного ящика» тестирования api недостаточно. также, если вы сталкиваетесь с ошибками и пишете дополнительные тесты для предотвращения регрессий, может потребоваться проверка материала <code>private</code>.</p>

<p>желание протестировать приватных членов - это запах дизайна, обычно указывающий на то, что внутри вашего класса есть класс, который пытается вырваться. вся функциональность класса должна быть реализована с помощью его открытых методов; функциональность, к которой нет публичного доступа, на самом деле не существует.</p><p>есть несколько подходов к пониманию того, что вам нужно проверить, что ваши частные методы выполняют то, что говорят на жестяной банке. классы друзей - худшие из них; они привязывают тест к реализации тестируемого класса таким образом, что является prima facie уязвимым. несколько лучше внедрение зависимостей: создание атрибутов класса зависимостей приватных методов, которые тест может предоставить макетированные версии, чтобы позволить тестирование приватных методов через открытый интерфейс. лучше всего извлечь класс, который инкапсулирует поведение ваших приватных методов в качестве открытого интерфейса, а затем протестировать новый класс, как обычно.</p><p>для более подробной информации, обратитесь к <a href="http://books.google.com.br/books/about/clean\_code.html?id=\_i6bdeocqzsc">чистый код</a> .</p>

<p>несмотря на комментарии относительно целесообразности тестирования закрытых методов, предположим, что вам действительно нужно ... это часто имеет место, например, при работе с устаревшим кодом перед преобразованием его в нечто более подходящее. вот образец, который я использовал:</p><pre><code>// in testable.hpp: #if defined unit\_testing # define accessible\_from\_tests : public # define concrete virtual #else # define accessible\_from\_tests # define concrete #endif </code></pre><p>затем внутри кода:</p><pre><code>#include "testable.hpp" class myclass { ... private accessible\_from\_tests: int sometestableprivatemethod(int param); private: // stuff we don't want the unit tests to see... int somenontestableprivatemethod(); class impl; boost::scoped\_ptr<impl> \_impl; } </code></pre><p>это лучше, чем определение тестовых друзей? это кажется менее многословным, чем альтернатива, и в заголовке ясно, что происходит. оба решения не имеют ничего общего с безопасностью: если вы действительно беспокоитесь о методах или членах, их нужно скрыть внутри непрозрачной реализации, возможно, с другими средствами защиты.</p>

<p>иногда требуется тестировать частные методы. тестирование можно выполнить, добавив friend\_test в класс.</p><pre><code>// production code // prod.h #include "gtest/gtest\_prod.h" ... class prodcode { private: friend\_test(prodtest, isfooreturnzero); int foo(void* x); }; //test.cpp // testcode ... test(prodtest, isfooreturnzero) { prodcode prodobj; expect\_eq(0, prodobj.foo(null)); //testing private member function foo() } </code></pre>

<p>в c++ есть простое решение с использованием #define. просто оберните включение вашего "classundertest" следующим образом: </p><pre><code>#define protected public #define private public #include <classundertest.hpp> #undef protected #undef private </code></pre><p>[кредит переходит к этой статье и ronfox] [1]</p>