What motivates implementing a setter method under TDD unless there is a test that requires it to exist and work?? Extra tests would only be required if we also need to implement is<X>Modifiable() for some field X.
If we're gonna be like that, wouldn't you need a test for every modifiable field? :)
Just because an object has a method implemented to "know" whether or not a field is modifiable?does not mean that that method is correctly implemented.? If there is such a method, you would still have to have at least two tests that verifies returns true only when that field is actually modifiable and false only when it is not.??
Unless the application itself needs such a method, I would have a test that gets the fields value, sets it to a different value, and gets the field value to verify it changes.
Ron Jeffries
Master your instrument, master the music, then forget all that shit and just play. -- Charlie Parker
