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;
Saturday, July 31, 2010
Subscribe to:
Post Comments (Atom)


No comments:
Post a Comment