Google Testing and Mocking frameworks overview

Google's guys that their Testing (take a look into the link to see the purpose) and Mocking (take a look into the link to see the purpose) frameworks can provide ligtweight and rich solution for unit testing over xUnit. Sounds interesting for me but not as the solution user so far. Eventually I want walk through the source codes and documentations in order to grab potential patterns, practices and maybe one day will come up with reusing those fixtures.

The detailed How to (not for dummies) are here (Testing) and here (Mocking)
Super! The use and syntax are really easy as both give you high-level macro instructions and capability to manipulate various (sometimes tricky) parameters. Basically the parameters are designed in source as flag resolver. The Testing FW (framework) advanced things like parametrized and typed tests are implemented in polymorphic template style with some ugly code geration (gtes-param-test.h). It's interesting to note that Testing and Mocking FWs attempts to give you a tool to model behaviour and workflows, various assertions just can ease and reduce testing code but the set of verifiers will not make revolution in testing. Here is a mocking style example:

using ::testing::InSequence;
using ::testing::Return;
...
{
InSequence s;

for (int i = 1; i <= n; i++) {
EXPECT_CALL(turtle, GetX())
.WillOnce(Return(10*i))
.RetiresOnSaturation();
}
}

the Testing excercises:

// Tests that the Foo::Bar() method does Abc.
TEST_F(FooTest, MethodBarDoesAbc) {
const string input_filepath = "this/package/testdata/myinputfile.dat";
const string output_filepath = "this/package/testdata/myoutputfile.dat";
Foo f;
EXPECT_EQ(0, f.Bar(input_filepath, output_filepath));
}

// Tests that Foo does Xyz.
TEST_F(FooTest, DoesXyz) {
// Exercises the Xyz feature of Foo.
}

} // namespace

int main(int argc, char **argv) {
::testing::InitGoogleTest(&argc, argv);
return RUN_ALL_TESTS();
}

You can easily inline your tests and mocks into source code (as well as make mocking as part of tests), just need to take care about proper headers inclusions.
The implementation looks like standart xUnit's
namespace {

// The fixture for testing class Foo.
class FooTest : public ::testing::Test {
protected:
// You can remove any or all of the following functions if its body
// is empty.

FooTest() {
// You can do set-up work for each test here.
}

virtual ~FooTest() {
// You can do clean-up work that doesn't throw exceptions here.
}

// If the constructor and destructor are not enough for setting up
// and cleaning up each test, you can define the following methods:

virtual void SetUp() {
// Code here will be called immediately after the constructor (right
// before each test).
}

virtual void TearDown() {
// Code here will be called immediately after each test (right
// before the destructor).
}

// Objects declared here can be used by all tests in the test case for Foo.
};

The testing FW provides inheritance from Environment down to test case down to tests so that generic methods and properties will override parent's implementation.

The Testing FW clasess self-explaining ones by the names - listed below (taken from internal namespace):
class AssertHelper;
class DefaultGlobalTestPartResultReporter;
class ExecDeathTest;
class NoExecDeathTest;
class FinalSuccessChecker;
class GTestFlagSaver;
class TestInfoImpl;
class TestResultAccessor;
class TestEventListenersAccessor;
class TestEventRepeater;
class WindowsDeathTest;
class UnitTestImpl* GetUnitTestImpl();
void ReportFailureInUnknownLocation(TestPartResult::Type result_type,
const String& message);
class PrettyUnitTestResultPrinter;
class XmlUnitTestResultPrinter;

F-1 round ride Kremlin in Moscow today

Today I have watched Formula-1 bolides nearby Kremlin in Moscow. It's warth to first time observe such road-jets (can't say cars) just in few steps from myself!


These are very reactive and noisy. Actually the noise is felt by skin - FANTASTICALLY!
The next time I hope I will see real race.

Unfortunate thing - I did not take a camera, trying to catch on mobile phone was failed cause F-1 is very fast :)

Code Refactoring - once you meet it...

The world changes continously, just so software code should pass through changes too. Basically lifecycle is following:

1. Prototype or simple model
2. Design as skeleton
3. Design refactoring
   
4. Some stuff is implemented
5. Refactoring should be done over new stuff
6. Code and design are ready
7. But code and design fit badly (inefficient memory management, resource leaks, security flows, unstable run, weak code support, improper interfaces and technologies, code smells...)
8. Run new refactoring. Dangerous and nightmare as hard!

* This imagination from standpoint of refactoring only. Change requests, new features and bugs and emergency wishes can appear between any of listed steps! Some projects recursively call Step #1 along any Step #X. Better case if you enjoy a few iterations 4-5-4, 6-7-6 or 7-3-7

The tool for refactoring is refactoring :)
The standard simple approach is to collect all code issues in defect tracker, assign to a proper player, come up with refactoring method, define expected results and benefits, estimate cost of fix and plan it. Once a refactoring item is ready - it should be tested inside and outside (Integration), unit tests (if exists) should give green (or rework them to meet with code changes). The last step is integration to production, QA testing and verification that "Refactoring is took place and results in expected out"

Usually refactoring is a step after code review or informal design/code inspection. The motivation to run refactoring should be as inside as outside, i.e. inside - when lead developer or architect initiate code review process and outside - when QA or customers or management have complains on product quality caused by bad design or coding.

Why refactoring is painful? Simply, more works done behind - more risks and potential affecting points on each refactoring item. And higher cost of refactoring. The same as for defects discovering and fixing - rate is continiously rising to production. Do you remeber this curve?

Consequently, frequent code review - less painful refactoring and less cost totally on refactoring. The general motivation of refactoring should be improve quality attributes of software, don't be driven by this task as something fancy or trendy.

Now, it's time for technical matter - some refactoring methods most used in industry. The good list of refactorings is listed here (http://www.refactoring.com/catalog/). The list is clearly complicated and easy to understand for those who are familiar with refactoring and coding practices, almost all links show up briefly meaning and how to apply with code excerpts and or UML diagrams. Most of the items can be fit and applied to automated testing either your code in scripting languages or real object oriented languages.

Basically we can break down refactoring approached to 2 groups: running top-down and running down-top. The first presumes review and improvements from highest levels (architecture and design) lowering to lines of code. The second method - is vice versa. Refactoring is not only finding and fixing issues in code pieces, it's also about designing proper patterns up to level of general architecture. Some time ago I made a post on patterns applied for automated testing 20 Essential design patterns for automated testing, however we can use it to revise the current design.