This is language agnostic. I want to develop a simple custom assertion class using test driven development.

The class will have an assert method called assertCarIsNotDamaged which will check if a person's car has no damage. It will check a hash map of car parts and their desired status with the status of the parts of a person's car.

For example, say a good car's "windShieldStatus" should be "ok" only and the persons car's "windShieldStatus" is "broken". Given this condition, the assertion should throw an error with this information.

My problem: I have a challenge in testing unit testing it. Should I make the assertion return a hash map of bad values and have my unittests check that the assertion failed only because of exactly these bad values and no other reason ? Should assertions always return nothing ?

Unfortunately, I have constraints. I have been told not to modify the "CarStatus" class. So, basically, I can't write an equals method to check if car statuses match. I am supposed to use a custom assert to check equality of objects. (IDK why someone would want it that way ;) ).


What about

 Test IsCarOK
   assert(IsWindshieldOK, Yes)
   assert(AreTiresOK, Yes)

Any failing assertion will result in test failing. Though what you are describing is more of a function rather than a test.

You will want to setup the test cases by setting windowOK to broken and then assert (iscarOK, No) that would be a proper test for a broken car, and you will have to explicitly mention the bad values and explicitly mention the good values. There might be an easier design pattern for what you are attempting to do.

| improve this answer | |
  • Can you please tell me why putting all related conditions into one assert is disadvantageous or bad ? – Erran Morad Oct 13 '16 at 18:48
  • 3
    @BoratSagdiyev Let's say you have assert(a && b && c && d). Your test fails, and you probably get a message saying Expected: True, Actual: False. How do you know which variables are false? You'll most likely have to resort to using a debugger, printing the statements or parsing the code manually to understand what may have happened. Had you had all these asserts separately, you'd immediately see what: "Oh, it failed because the windshield was broken, let's see why." – Vincent Savard Oct 13 '16 at 18:56
  • More like there should be a function that does that in your code. isCarOK and your testing should test whether that functions work correctly. Using a test to determine if a car is OK doesn't make sense to me. Tests are there only to say what is correct. so if a window is broken IsCarOK should be false. If all parts are good (the individual asserts or setup) then IsCarOK should be true. HTH – Parivar Saraff Oct 13 '16 at 19:08
  • @VincentSavard - Thanks. That makes sense. I was wondering if I could make the custom assert print an error message about what is wrong. Eg. "Assertion Failed because: Car is bad. Expected 'windShieldStatus' to be 'ok', but got 'chipped'; Expected 'correctCarLength' to be '12ft', but got '10ft' (maybe you gave a wrong car or the car is crushed in an accident?) " ? – Erran Morad Oct 13 '16 at 19:11
  • 2
    I think given the simple tests & assertions we have you should be able to write test for any complex case. Creating custom return values and other functions seems to me like a case of solving the wrong problem. This is more of a code design issue than a testing issue. But yes coming up with the correct tests will greatly help understand and design the code better. – Parivar Saraff Oct 13 '16 at 19:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.