tag:blogger.com,1999:blog-9099907.post7138854699062222755..comments2021-10-26T20:42:19.297-07:00Comments on Rebecca's Blog: Design For TestRebecca Wirfs-Brockhttp://www.blogger.com/profile/02844092142697047388noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-9099907.post-63726472663011357772009-08-14T12:10:28.682-07:002009-08-14T12:10:28.682-07:00Yep... interfaces are best understood when demonst...Yep... interfaces are best understood when demonstrated. So I like to see how they are used, too. But a lot of tests can be difficult to wade through. So somehow, I'd like to see a good way of separating out what not to do (when using an interface) tests, from what to do tests. And labeling them somehow.Rebecca Wirfs-Brockhttps://www.blogger.com/profile/02844092142697047388noreply@blogger.comtag:blogger.com,1999:blog-9099907.post-47756031719541793812009-08-14T07:18:22.107-07:002009-08-14T07:18:22.107-07:00That's a good article about Design for Test. ...That's a good article about Design for Test. Another thing that I like about TDD is that it has this "side affect" of creating API documentation. As a programmer I always like to see how an API is used in some context rather than just see a document that says, "here is API x that does y". At least with the test cases you can see how the API is used. Through some clever Doxygenation, one or more of the test cases can even be a part of the documentation for a class.Johnhttps://www.blogger.com/profile/02579700312866732318noreply@blogger.com