{"id":470,"date":"2010-03-05T11:41:20","date_gmt":"2010-03-05T18:41:20","guid":{"rendered":"https:\/\/simpleprogrammer.com\/?p=470"},"modified":"2018-04-12T01:26:35","modified_gmt":"2018-04-12T05:26:35","slug":"the-ego-test","status":"publish","type":"post","link":"https:\/\/simpleprogrammer.com\/the-ego-test\/","title":{"rendered":"The Ego Test – Test Cases That Just Won’t Fail"},"content":{"rendered":"

You know those tests you like to run? \u00a0You know what I mean, those test cases that always give you a green bar and never fail?<\/p>\n

If you are having a bad day, and you feel like nothing is going right, you can just “right-click” run and you get a nice 100% passing green bar. \u00a0It is easy to refactor the code those tests are testing, because you know in your heart that no matter how much you change the code, those tests will always pass. \u00a0What a great feeling. \u00a0Doesn’t that make you feel like the king of the world?<\/p>\n

I like to call those tests Ego Tests<\/strong>, because they are the\u00a0equivalent\u00a0of code flattery. \u00a0An Ego Test always validates you. \u00a0It tells you your code is pretty when it really has a fat butt. \u00a0The Ego Test says “you can do nothing wrong.” \u00a0The Ego Test says that “everything is going to be ok.” \u00a0That is until you roll the code out to production and everything breaks. \u00a0Then when you look for the Ego Test, you realize his message of “GREEN IS GOOD” is still blaring at full volume in an endless repeat cycle, like a mantra, or one of those self-hypnosis, “you can quit smoking” tapes. \u00a0He is not really your friend; he is just a recording stuck in an endless loop. \u00a0He won’t help you fix your bugs, he won’t even tell you they exist.<\/p>\n

He must be stopped!<\/strong><\/p>\n

\"\"<\/a><\/span><\/strong><\/p>\n

Identifying the Ego Test<\/h2>\n

The Ego Test can be any kind of test from unit test to automated functional test and more.<\/p>\n

The Ego Test is identifiable by one or more of the following characteristics:<\/p>\n

    \n
  1. Does not contain asserts.<\/li>\n
  2. Contains asserts which only assert on conditions which are always true such as: \u00a0assertTrue(isJohnSonmezCool?true:true);<\/em><\/li>\n
  3. Asserts on things which are not related to what you are testing.<\/li>\n
  4. Catches exceptions and eats them so the test will not error out.<\/li>\n
  5. Tests things through a mock, but then does not assert the mocking expectations are satisfied.<\/li>\n
  6. Never fails, no matter what you do to the code.<\/li>\n<\/ol>\n

    You would think from this list it would be pretty easy to stop and catch an Ego Test. \u00a0It is not always so easy. \u00a0Many Ego Tests appear to be testing the right thing, or seem like they could fail even though they can’t.<\/p>\n

    One quick way to figure out if you have an Ego Test is to change the input to the test and see if it fails. \u00a0If you think you are looking for the word “Blue” in a drop down, and you change the HTML being tested to not contain the word “Blue” in the drop down, and if the test still passes, you have a problem.<\/p>\n

    Avoiding the Ego Test<\/h2>\n

    The Ego Test is fairly easy to avoid. \u00a0The best way is to make sure your test will fail when you change the input. \u00a0Most of the time you can do this by changing the source code temporarily to produce a result which should be a failure. \u00a0Sometimes though, you don’t have the ability to change the source code or doing so would be more work than it is worth. \u00a0In those cases, you can change the test instead, to test for a condition which should not be true. \u00a0Be very careful here though, many people are tripped up trying to validate tests the second way because they simply invert an assert statement.<\/p>\n

    For example, if you have an assert that is<\/p>\n