Google Mock Sequence

We have had a problem in our software for some time now that has caused plenty of frustration and headaches. We have a method that when it is called it builds a pipe-delimited string of values by looking up different pieces of data that had been saved off earlier. The string that is returned needed to have the values in a specific order; the reason behind this is that this string was parsed by an .asp page that had no knowledge of the order of the values. Anytime a developer would change the order of the values, it would break the web application that used these values. We all agree that this is an awful way of doing things but we currently have technology constraints that will not let us change this.

We have tried to educate the developers not to add items in the middle by sending the information out in emails, mentioning this in team meetings, and even putting comments in the code. Without fail though, someone will be in a hurry and forget about this and the next time someone goes to test the web application, it will have been broken.

Google Mock has a way to group expectations into a sequence that will cause the test to fail if not used in the proper order.

using ::testing::InSequence;
{
  InSequence pipeDelimitedStringOrder;

  EXPECT_CALL(...)...;
  EXPECT_CALL(...)...;
  ...
  EXPECT_CALL(...)...;
}

Now if a developer goes to change this method, they will see that the tests fail and will (hopefully) add any new methods to the end of the list.

Code Smells

Here are a few more links to code videos. Jason Gorman (www.codemanship.com) shows different code smell examples and what to do to get rid of them. All examples are screen casts in Java.

• Feature Envy - method that makes multiple calls to another class
• Data Clumps - multiple fields on a class that belong together in their own class
• Inappropriate Intimacy - Feature Envy in two directions
• Divergent Change (second video) - classes that violate the single responsibility principle
• Duplicate Code - same code in more than one place
• Message Chains - Law of Demeter violation, only interact with your nearest neighbors
• Switch Statements (second video) - use Polymorphism instead
• Lazy Classes (second video) - classes/subclasses that do too little to justify the overhead of their existence
• Data Classes - classes with fields, getters, and setters but nothing that operates on those fields
• Long Parameter Lists - self explanatory, I feel
• Copy/Paste Inheritance - two classes with same/similar fields/operations with not much different between the two
• Long Method - method that does more than it needs to, doesn't necessarily have to be a large method
• Comments - code should mostly be self explanatory

Code Video sites

Here are a couple of good sites for watching videos related to programming and testing:

http://jamesshore.com/Blog/Lets-Play/
http://confreaks.net/
http://misko.hevery.com/presentations/

I'll update this as I find other sites that I think are good resources.

Google Mock: Leaking Mocks

There are a couple of ways to deal with Mocks that leak. An error will print like the following:

1>.\Tests.cpp(76): ERROR: this mock object (used in test Tests.SampleTest) should be deleted but never is. Its address is @00E659C8.

1>ERROR: 1 leaked mock object found at program exit.

1>Project : error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

This is an indication of either not calling delete on a pointer that was newed previously, or if the pointer is being deleted, an exception could be being thrown in the destructor of the Mocked class.


The first way is to set the command line argument to include

--gmock_catch_leaked_mocks=0

In our project, we have the test executable running after the project is built so this can just be added to the end of the Post-Build Event in the project properties.

The second way is to say in the test that the specific Mock that you are using can allow leaks.

using ::testing::Mock;
... 
Mock::AllowLeak(mockThatLeaks); 

If your problem is that an Exception is being thrown in the destructor, it should be determined why the Exception is being thrown. It could be that it's just because the class isn't initialized properly in the test or that there really is a problem that should be looked into and fixed.

Another Clean Code Talk

Here is a link to another Clean Code talk from Google. It's an interesting lecture about removing if statements and switch statements from code using Polymorphism.

Inheritance and Polymorphism

Setting up a C++ project with Google Mock/Google Test in Visual Studio 2008

Steps that I had to take to get a C++ project setup to use Google Mock and Google Test: (assumes that Google Mock and Google Test has already been downloaded and compiled)

1. Add a New Project to the solution
1. Right-click on Solution - Add > New Project
2. Select Win32 Console Application
3. Give it a name
4. Click Ok
5. Click Finish on the Wizard that pops up
2. Change the Project Properties
1. Change Configuration at the top to All Configurations
2. Under Configuration Properties > General > Use of MFC
• Change the selection to be Use MFC in a Shared DLL
3. Under Configuration Properties > C/C++ > General > Additional Include Directories
1. Add the path to the include folder for Google Mock
• Ex. - ..\..\CoreThirdParty\gmock-1.5.0\include
• (CoreThirdParty is a directory that houses Google Mock, Google Test, and other Third Party headers and libraries that our project depends on)
2. Add the path to the include folder for Google Test
• Ex. - ..\..\CoreThirdParty\gtest-1.5.0\include
4. Under Configuration Properties > Linker > General > Additional Library Directories
1. Add the path to the Release folder for Google Mock
• Ex. ..\..\CoreThirdParty\gmock-1.5.0\msvc\Release
5. Under Configuration Properties > Linker > Input > Additional Dependencies
1. Add the libraries for Google Mock
• gmock.lib
• gmock_main.lib
6. Under Configuration Properties > Build Events > Post-Build Event > Command Line
1. Add the command to run the executable after the build is finished
• "$(TargetDir)$(TargetFileName)" --gtest_filter=*.* --gtest_shuffle --gtest_output=xml
3. Add a HookUpTest to the .cpp file
1. Remove all of the code in the .cpp file that was created with the project
2. Add the following code to create a HookUp Test

#include <gmock/gmock.h>

TEST(SimpleTest, HookUpTest)
{
    ASSERT_TRUE(true);
}

Build this project and hopefully the output will be:


1>Finished generating code
1>Embedding manifest...
1>Performing Post-Build Event...
1>Running main() from gmock_main.cc
1>[==========] Running 1 test from 1 test case.
1>[----------] Global test environment set-up.
1>[----------] 1 test from SimpleTest
1>[ RUN      ] SimpleTest.HookUpTest
1>[       OK ] SimpleTest.HookUpTest(0 ms)
1>[----------] 1 test from SimpleTest(0 ms total)
1>[----------] Global test environment tear-down
1>[==========] 1 test from 1 test case ran. (0 ms total)
1>[  PASSED  ] 1 test.