First are the requirements. Then comes a test that fails and then the implementation of the requirement. That may cycle until the code fulfills the requirement. Finally move to the next requirement and repeat. That is TDD. Writing unit tests to check that getters and setters work has little to do with TDD.
I guess the point of this article was to encourage people who associate testing with TDD that there's more to testing than the order in which you do it. Thanks for your comments.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First are the requirements. Then comes a test that fails and then the implementation of the requirement. That may cycle until the code fulfills the requirement. Finally move to the next requirement and repeat. That is TDD. Writing unit tests to check that getters and setters work has little to do with TDD.
I guess the point of this article was to encourage people who associate testing with TDD that there's more to testing than the order in which you do it. Thanks for your comments.