tag:blogger.com,1999:blog-12467669.post7713579041565835007..comments2023-04-29T07:23:25.825-04:00Comments on Jay Fields' Thoughts: Testing: Duplicate Code in Your TestsJayhttp://www.blogger.com/profile/14491442812573747680noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-12467669.post-34552922467150785282008-09-02T00:20:00.000-04:002008-09-02T00:20:00.000-04:00@anonymous "Programming is about representing know...@anonymous "Programming is about representing knowledge in a machine readable format." I this this is the point. Isn't testing supposed to be close to a human readable format? Isn't that why we all love the .should sweetness? <BR/><BR/>I agree that maintaining a test suite requires a certain effort, regardless having DRY or explicit code. I think the ultimate question is do you want to maintain DRY test or explicit test? I'd rather have DRY code in my app, and explicit tests.<BR/><BR/>Hope to get some feedback from you.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-37519721101087919082008-06-12T04:17:00.000-04:002008-06-12T04:17:00.000-04:00Anonymous:I appreciate your opinions. Clearly you ...Anonymous:<BR/><BR/>I appreciate your opinions. Clearly you are so confident in your assertions that you've left your name... oh.. nevermind.<BR/><BR/>Your comment is, to quote you: "pure nonsense"<BR/><BR/>I wish testing were as simple as you make it sound; unfortunately, <A HREF="http://blog.jayfields.com/2008/06/developer-testing-and-importance-of.html" REL="nofollow">developer testing is highly dependent on context</A> and your context is clearly significantly different than mine.<BR/><BR/>I disagree with almost every claim you make, some of which I would also characterize as FUD. But, there's little value in continuing the debate with "unnamed sources" who have incredibly narrow visions of the world. So, I'll chalk it up to, agree to disagree.<BR/><BR/>Cheers, JayAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-8089345901248309322008-06-11T15:04:00.000-04:002008-06-11T15:04:00.000-04:00The only place duplication should have in computin...The only place duplication should have in computing is in redundancy. The three strike rule, as it applies to refactoring, and especially refactoring test code, trumps your argument here.<BR/><BR/><EM><BR/>The problem is that it's much easier to understand how to apply DRY than it is to understand why. </EM><BR/><BR/>I couldn't disagree more, this is pure nonsense. How you remove duplication depends wholly on the situation. Why you remove duplication is, in fact, a very easy thing to understand.<BR/><BR/>Programming is about representing knowledge in a machine readable format. A computer can easily duplicate knowledge if you tell it to; copying is really cheap for a computer. No matter how sophisticated you make your algorithms, it's ultimately up to a human to tell the computer which piece of knowledge he/she needs. Until computers can read minds, this is the single most important reason to fight duplication. <BR/><BR/>The fact that you think the DRY principle means make things more complicated is just surrounding it in FUD. All it says is that knowledge should have a single authoritative representation in a system. There are many ways to keep things simple while removing duplication, and any effort invested here will increase overall maintainability.<BR/><BR/>The only difference when you're working with tests is that they don't stand on their own and will change with the code they test. You have to swallow this assumption as soon as you decide to write tests - it's not anything to be scared of. The better you become at writing tests, the more valuable they will become. And anyone will tell you, when working with tests, the hardest problem you're going to come across is maintenance. This is why the best advice I can give is to adhere to the DRY principle when writing tests.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-23128743203776578282008-05-14T04:12:00.000-04:002008-05-14T04:12:00.000-04:00Interesting post and I have a couple of comments.*...Interesting post and I have a couple of comments.<BR/><BR/>*Loosely couple objects*<BR/>I'm just not sure how practical it is to make it so that a domain model is always incredibly easy to use in tests particularly when often tests do not use the domain objects in the same way as the rest of the system does (e.g. give me a Completed order).<BR/><BR/>As an example design wise it may make sense to pass a Customer to an Orders constructor but it makes it harder to use an Order in tests. Also unless I model each state as a seperate class (ActiveOrder entity) I may have to go through multiple steps to get an object ready for use in tests, if I don't use a builder/object mother then this could result in a heck of a lot of duplication.<BR/><BR/>Test Fixtures<BR/>I agree about the problems with small focussed test fixtures but you can keep them all in one file or otherwise organize them to make it easier to navigate and I think it also has a lot of advantages in making the tests easier to read and understand. You just look at setup methods (which are short and sweet for unit tests) and the test (if possible just doign the assert). Have to say I like both approaches, which is a total cop out.Colin Jackhttps://www.blogger.com/profile/01403166737046938219noreply@blogger.comtag:blogger.com,1999:blog-12467669.post-80450113439844015822008-05-13T12:23:00.000-04:002008-05-13T12:23:00.000-04:00Call me persuaded but unconvinced. Perhaps it is ...Call me persuaded but unconvinced. Perhaps it is a lack of clarity about what you are advocating. I have been reading through the Merb-core test suite which uses rspec. The Merb team actually points people to there test suite as a form of documentation, so the think that the tests are readable and easy to follow. On the other hand the Routing tests in particular have a lot of DRY refactoring to them. Much of the common code is refactored into helper methods, which mean that there are several places to look to find why a test is failing.<BR/><BR/>It is hard to talk in merely hypothetical terms about this, at least for me. If you have looked at the Merb-core tests, what do you think of them? Are they DRY to the point where they are not helpful, or does this kind of refactoring add to readability and brevity?<BR/><BR/><A HREF="http://github.com/wycats/merb-core/tree/master/spec/public/router/special_spec.rb" REL="nofollow">Link to example spec</A>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-20205242834465973662008-05-13T12:17:00.000-04:002008-05-13T12:17:00.000-04:00Could you show an example of the poorly designed G...Could you show an example of the poorly designed Gateway class and its tests that require a setup method, and compare it with a well-designed one whose tests require minimal stubbing?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-44657302320835470752008-05-13T09:53:00.000-04:002008-05-13T09:53:00.000-04:00Nice post. You should point out that this is not a...Nice post. You should point out that this is not a new concept. The process originally laid out by Kent Beck in his TDD book was:<BR/><BR/>* Red Bar<BR/>* Green Bar<BR/>* Remove duplication (between the test and the code)<BR/><BR/>I care a lot about test autonomy though. So given the choice, I'll accept some level of duplication to achieve that -- but it is a balance for sure.<BR/><BR/>Cheers!<BR/>ClintonAnonymoushttps://www.blogger.com/profile/00558779246463349899noreply@blogger.comtag:blogger.com,1999:blog-12467669.post-54021565631488416152008-05-13T00:16:00.000-04:002008-05-13T00:16:00.000-04:00You beat me to my first point with the mention of ...You beat me to my first point with the mention of transactions. I think thats a prime example of something that would be silly to have in each and every test, although it can definitely be unclear as to whats happening when code like that is defined in a method you don't know exists...<BR/><BR/>That being said, while I agree with many of your points, I spent that last two weeks or so going over hundreds of tests across all of the layers of a huge rails app. Some places certainly would have benefitted from the lack of a setup/teardown method--your point of about tests depending on others tests is excellent and very real. <BR/><BR/>However, I cringe to think of what some of these tests would look like without setup and teardown. Perhaps it wouldn't be as bad as I'm imagining. Maybe I just need to see it in action to really get it. <BR/><BR/>Given that you've brought this up before, and will hopefully again, it might be valuable to take a real life test file and rework things as you'd prefer. For instance, the one assertion per test rule is something I like very much, but also can only wonder how it'd work with some of these older tests I've seen others write. Hard for me to imagine things not ballooning out of control. <BR/><BR/>Anyway, thx for the great thoughts and writeup as always, and hope to see some of this in action.Jack Dempseyhttps://www.blogger.com/profile/17940809933407388413noreply@blogger.com