@DrPepper said:
It doesn't actually create a test method for each property: there's just one test method which iterates over all properties and reports failures. So you can't override the test, but you can implement a test and remove that property from the initial configuration list of "simple properties". That's one reason why you don't find the properties reflectively - sometimes the naive getter/setter test doesn't fit what your methods do - the other reason being you want to make assertions about the properties that exist.Cool idea; could you use reflection to find the setters/getters? And do you have overrides/other tests for getters/setters that have complex business logic? (Thinking of a getter that returns the full name of a person from the firstname/lastname properties, for example)
For example, we bind our domain objects to screen components reflectively, and enable and disable them reflectively using property names - so we have constants in the classes for each property name, which we use for the arguments in the tests. This way if there's a typo in the constant, the tests catch that.