I'm looking at your test, and it looks like you based it off of the friction test, which I thought was a nice way to set up the test. I think there is an even better way to set up models now, introduced in pull request #1466. Instead of using string streams and xml, the model properties can be encoded in protobuf messages and then used to spawn models programmatically.
We have migrated a few tests to this new way, but I hadn't gotten to the friction test yet, since I had been hoping to make some larger changes to the friction parameters.
Long story short, do you mind trying to use the protobuf interface for that test? I can advise on how to make the modifications, though there is a decent example in pull request #1744 (joint_test.hh) and also the GetWorldInertia test.
I updated the test, but this had the cost of slightly increasing the complexity of the PR:
the provide_feedback option was not exposed in the msg::Joint (or I was not able to find it),
so I had to use the SetProvideFeedback method. This method had several bugs, so I had to fix it 
before migrating the test.
I ran a coverage build for this branch last night.
I noticed that the newly introduced functions have only about 28% function coverage, which sort of makes sense since most functions are meaningless for fixed joints. My question is, do we care about the coverage here (we're trying to improve the coverage on all new pull requests)? Should there be tests calling these functions at least to make sure they don't break anything? I think that would be quick to implement...
Nathan Koenig ?
I guess all that different dummy implementations could be avoided with a slightly different joint structure.. but this is out of the scope of this PR.
Let me know what do you think it make sense to do in the short term.
I think we could add the fixed joint type to the SpawnJointRotational* tests. These tests are applied to joints that have all three translational directions constrained (revolute, ball, universal). The SpawnJointRotational test creates a parent and child link connected by a joint, applies a linear velocity to the parent link, and verifies that the child follows. The SpawnJointRotationalWorld test creates a link and attaches it to the world through a joint, both as parent and child, and then verifies that it doesn't fall with gravity turned on. Here's a patch to enable it:
diff -r bdc3eba2e76b test/integration/joint_spawn.cc--- a/test/integration/joint_spawn.cc Mon Jun 29 10:25:45 2015 -0700+++ b/test/integration/joint_spawn.cc Sun Jul 19 16:10:28 2015 -0700@@ -492,6 +492,7 @@
+ , "fixed"
// Skip prismatic, screw, and revolute2 because they allow translation
@@ -499,6 +500,7 @@
+ , "fixed"
int main(int argc, char **argv)