Using git to add a submodule

The command to add a submodule to a project is:

git submodule add <URL of the submodule repo> <path to place submodule> 

Example:

git submodule add git@1.1.1.1:Submodule.git ./Submodule 

This will modify the .gitmodules file in the repository. When I ran this command, I got a fatal message stating:

fatal: LF would be replaced by CRLF in .gitmodules

Failed to register submodule 'Submodule' 

Modifying the .gitmodules file manually by replacing the LF with a CRLF fixed this problem (ie. open the file in Notepad++ or another text editor, delete the end of line character, and hit 'Enter' on the keyboard for each of the new lines added for this submodule).

Running the command

git submodule status

will show that this submodule isn't ready to be used as of yet. Run

git submodule init

to initialize this submodule. You should not need to run update for this submodule because the clone happened when the submodule was added.

Add, commit, and push this file so that other users will be able to have the changes.

Clean Code Talks

Here are a few links to Clean Code talks at Google dealing with unit tests. Pretty interesting and useful information.

Don't Look for Things

Law of Demeter

He teaches that in a constructor you should ask for what you need and don't look for things. Meaning, don't pass in a user object when what you really need is a username and password.

Unit Testing

Google Test/Mock: 3rd Party dll dependency

One of our projects relies heavily on third party API calls. I have already alluded to the pain involved in getting the project setup just to be able to write a HookUp test. After several linker errors and header files that were not referenced, we were finally able to get the test project to compile. When a test project is compiled and built, the tests are supposed to run as well and give an indication of whether or not the tests passed or failed. The output window in VS should show this:


13>[==========] Running 1 test from 1 test case.
13>[----------] Global test environment set-up.
13>[----------] 1 test from Tests
13>[ RUN      ] Tests.HookUp
13>[       OK ] Tests.HookUp (3286 ms)
13>[----------] 1 test from Tests (3286 ms total)
13>[----------] Global test environment tear-down
13>[==========] 1 test from 1 test case ran. (3287 ms total)
13>[  PASSED  ] 1 test.


In this particular case though, we were not seeing the test output. Every project succeeded in building and compiling, but the test output was missing. All that was in the HookUp Test was instantiating a class with a no-op ctor. The ctor however was kind of messy and created several other classes that called into third party libraries.

Because the project compiled and built just fine it seemed that it was a run-time issue and that running the .exe from the command line may show other errors or give us a reason as to why the tests were not running. So, under Tools > Visual Studio 2008 Command Prompt, we changed our directory to the Release folder of the .exe. Running the .exe produced a System Error popup:

The program can't start because <3rd party dll> is missing from your computer. Try reinstalling the program to fix this problem.

There are a couple of options at this point: 1) copy all of the required dll's (in our case > 125) into the directory that the executable was running in, or 2) change our environment PATH variable to include the directory where these dll's were located. (There may be a third option, like remove the dependency on these libraries) Both are not ideal since these are unit tests and we do not want to have to do either of these on every developer's machine plus the build machine.

The solution ended up being setting the PATH environment variable in the post-build event's command line option of the project property's. This would modify the PATH variable to include all of the required dll's for the test executable and would not permanently modify this variable.

set PATH=%PATH%;..\relative\path\to\the\required\dlls;

$(TargetDir)$(TargetFileName) --gtest_output=xml

It seems as though this still is not ideal and we would love to not have to rely on these dll's at all in our test. Perhaps when we know more about mocking we will be able to remove this step from the project.

Google Mock Presentation at work

I've just completed a presentation of Google Mock during a lunch and learn at my work. I learned a number of helpful things in the past few weeks and hopefully was able to share what I've learned with my team in a way that was easy to understand.

The first thing that I learned was how absolutely awful it was to create a C++ test project and link it with all of the dependencies in our code. A lot of trial and error, searching google to find out the problems, and asking Cheezy from LeanDog for pointers in how to solve some of the problems.

I'll post again soon about some of the things that I learned working with Google Mock.