riddles
Riddle #2: Uniformity
We have a simple Widget with just two members for its position. The constructor simply initializes the fields. For the sake of this exercise, let's assume that in reality the Widget's constructor is doing much more to justify its existence over relying on the aggregate initialization.
#include <gtest/gtest.h>

struct Widget {
  Widget(int _posx, int _posy)
  : posx(_posx),
    posy(_posy)
  { }
  
  const int posx;
  const int posy;
};

TEST(WidgetTest, constructor) {
  const Widget widget(10, 10);
  EXPECT_EQ(10, widget.posx);
  EXPECT_EQ(10, widget.posy);
}
#include <gtest/gtest.h>

struct Widget {
  Widget(int _posx, int _posy)
  : posx(_posy),
    posy(_posx)
  { }
  
  const int posx;
  const int posy;
};

TEST(WidgetTest, constructor) {
  const Widget widget(10, 10);
  EXPECT_EQ(10, widget.posx); // FAIL! undetected simple bug in constructor
  EXPECT_EQ(10, widget.posy); // FAIL! undetected simple bug in constructor
}
#include <gtest/gtest.h>

struct Widget {
  Widget(int _posx, int _posy)
  : posx(_posx),
    posy(_posy)
  { }
  
  const int posx;
  const int posy;
};

TEST(WidgetTest, constructor) {
  const Widget widget(11, 12);
  EXPECT_EQ(11, widget.posx);
  EXPECT_EQ(12, widget.posy);
}
Can you spot a weakness in the test?
Give me a hint
Can you observe anything particular about the test data?
Reveal the answer
Diagnosis
One single value is used for multiple parameters. This test is pretty weak - it does not protect us from a family of simple but common mistakes: accidental swapping of the parameters or assigning the same one to multiple fields thanks to a copy paste mistake. Show me
It may seem like a trivial mistake easy to avoid, and even some IDEs are smart enough to detect such mistakes, but there is plenty of non obvious cases that can sneak through. I lost count how many times I confused latitude with longitude.
Reveal the remedy
Remedy
With such problem description, the remedy seems quite straightforward. Just use distinct values for distinct parameters to get more protection from your test. Show me
In some simple cases, this strategy also helps with debugging - if you encounter a variable with an unexpected value you may be able to more easily trace it back to its origin if the value is recognisable.
This strategy can also be applied to other data types, with string being of course the most friendly towards carrying values significant to a human.
In more complex tests involving managing multiple instances of mocks of the same type, it would be ideal to give names to all these instances. It could really boost the analysis of test failures, if instead of being told "unexpected call", we would hear "unexpected call on WidgetBeforeUpdate". Unfortunately, to my knowledge, there isn't a test framework in C++ with support for this. But I could imagine that e.g. in Java you could leverage the virtual toString() method to feed the runtime with the name of the mock.
Feedback on this riddle? 3c6120687265663d226d61696c746f3a666565646261636b407375737461696e61626c6563707074657374696e672e636f6d3f7375626a6563743d5375737461696e61626c6520432b2b2054657374696e672c20726964646c65233220666565646261636b223e446f2067657420696e20746f756368213c2f613e
<< Riddle #1: Exceptional || Riddle #3: Incomplete >>