Is it okay to allow a custom assertion to return something?

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.


Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *