In my application, I have a user settings form with roughly 20 checkboxes and a few other controls. The checked state, enabled state and texts of these controls are bound to about 60 properties of the presenter class, which is drawing the information from the model class with the business logic.

Now I wrote a unit test method "TestLoadData", where the LoadData method of the presenter class is called (which itself calls the LoadData method in the model, which then notifies the presenter).

After this, I have 60 assertions on the properties of the presenter class, followed by 40 assertions on the properties of the model class (20 "enabled"-properties are presenter only), because I want to check if every value is correctly loaded.

So I have a real big (100-lines) TestMethod, which I think is very bad test design.

(All numbers are approximated)

Is it better to write one small 5 lines test-method for each property? How much worse is it to have this big test method?

Does it really make a difference? Am I perhaps only too lazy to write 60 small test methods?

Or should the settings form depend on more than one presenter class, each holding only small parts of the 60 properties?

1 Answer 1


If I were you I would write small tests for each, because then it is much more eye catching what went wrong. While with one big test you only get 1 bit of information when running the test (either everything is ok, or something is bad), if you have a test for each property you will see which one (ore ones) are broken.

If the loading you make needs significant initialization, then put that into a test-init method. Unit test frameworks usually let you define a method that runs before every test method in a class.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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