tag:blogger.com,1999:blog-12467669.post3954855437655318414..comments2023-04-29T07:23:25.825-04:00Comments on Jay Fields' Thoughts: Testing: Inline SetupJayhttp://www.blogger.com/profile/14491442812573747680noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-12467669.post-49368610077492328562007-09-19T04:33:00.000-04:002007-09-19T04:33:00.000-04:00>>There's no getting around the fact that extracti...>>There's no getting around the fact that extracting a method adds complexity.<BR/><BR/>Hmmm... I don't think this is true in general.<BR/><BR/>Reusing code by extracting a method can both increase or decrease complexity depending on the circumstances.<BR/><BR/>If the method increases the cohesion and decreases the coupling of the code then it is decreasing complexity.<BR/><BR/>If it increases coupling and decreases cohesion then it is increasing complexity.<BR/><BR/>Note that decreasing cohesion is what you are refering to when you say that complexity has increased in this case.<BR/><BR/>Jonathan.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-89376765252063055712007-06-19T04:54:00.000-04:002007-06-19T04:54:00.000-04:00Hi Jay,Yes, comment conversation is like trying to...Hi Jay,<BR/><BR/>Yes, comment conversation is like trying to write Haiku :-)<BR/><BR/>I see what you're saying, and yet I still disagree. :-) I think that a 'good' developer won't rush to check in.<BR/><BR/>Defining 'good' of course, is a whole other conversation. Ward (of course) articulates it better than anyone has so far, I think: http://eclipse-projects.blogspot.com/2007/04/is-agile-too-easy.htmlAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-34481283786957381862007-06-15T10:36:00.000-04:002007-06-15T10:36:00.000-04:00Hello Alan,Sometimes it's tough to your your point...Hello Alan,<BR/><BR/>Sometimes it's tough to your your point across via comments. =)<BR/><BR/>I not trying to point out whether or not you misquoted me. I was trying to say that I don't believe only weak/bad developers don't read tests. <BR/><BR/>I think there can be other reasons that a good developer doesn't read a test, such as having a massive refactoring that started as a small change and went down a rabbit hole. At that point, I just want to get checked in and am not worrying about continuing to refactor bad tests I stumble upon.<BR/><BR/>Thanks for the comments all the same.<BR/><BR/>Cheers, JayAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-91861080947688246462007-06-15T03:05:00.000-04:002007-06-15T03:05:00.000-04:00Hi Jay,apologies... s/bad/weak/gAlanHi Jay,<BR/><BR/>apologies... s/bad/weak/g<BR/><BR/>AlanAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-19633379021311503712007-06-13T10:25:00.000-04:002007-06-13T10:25:00.000-04:00Hello Alan,I didn't say: Bad developers don't prop...Hello Alan,<BR/><BR/>I didn't say: Bad developers don't properly read the tests.<BR/><BR/>I don't believe that either. I think everyone at some point has needed to check in for one reason or another and stumbled upon a test that they couldn't make heads or tails of. In that case, I don't think it makes you a bad developer if you get the test working so you can check in and then refactor the test after you've gotten checked in.<BR/><BR/>However, I'm trying to avoid that situation entirely by getting the tests to a maintainable state in the first place.<BR/><BR/>Cheers, JayAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-66661075089408710292007-06-13T09:05:00.000-04:002007-06-13T09:05:00.000-04:00"You can claim that the above scenario only happen..."You can claim that the above scenario only happens when you have weak developers. You'd be wrong. I work with some of the best developers in the industry and it still happens."<BR/><BR/>Hmmm. <BR/><BR/>Bad developers don't properly read the tests.<BR/><BR/>It happens at ThoughtWorks<BR/><BR/>Therefore....<BR/><BR/>Two possible options there. Don't always believe your own press, dude. :-)<BR/><BR/>Alan<BR/>Disclaimer: I worked for TW for 4 years.Unknownhttps://www.blogger.com/profile/16267331017457092641noreply@blogger.comtag:blogger.com,1999:blog-12467669.post-45989353897626453682007-06-11T18:22:00.000-04:002007-06-11T18:22:00.000-04:00Daniel,Thanks, as always, for your comments. At t...Daniel,<BR/><BR/>Thanks, as always, for your comments. At the end of the day, we all have to make adjustments for our environment. While I think my plan scales well, I've never coded a day in your shoes. I've also never written a C extension. =)<BR/><BR/>Thanks for your point of view.<BR/><BR/>Cheers, JayAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-17419127663856184342007-06-11T18:16:00.000-04:002007-06-11T18:16:00.000-04:00Jay,Ah, ok, your original post made it sound like ...Jay,<BR/><BR/>Ah, ok, your original post made it sound like (to me, anyway) that the other testers didn't understand the purpose of a setup method and/or weren't familiar with testunit in general. My apologies.<BR/><BR/>As for RSpec, well, maybe that is a solution, but it's not one I've come around to personally yet. :)Daniel Bergerhttps://www.blogger.com/profile/05224445093970941579noreply@blogger.comtag:blogger.com,1999:blog-12467669.post-31559142242334258182007-06-11T17:26:00.000-04:002007-06-11T17:26:00.000-04:00Jay,I agree with your post, though it seems to als...Jay,<BR/><BR/>I agree with your post, though it seems to also point to a fundamental framework flaw. Test/Unit is almost forcing you to do per-test-setup, whereas RSpec allows for contexts with localized setup and teardown (what they call before and after). I think this goes a long way to remedying the problem you pointed out without all the need for duplication. Separate your testing concerns.<BR/><BR/>In my mind, there is no point "setting up" a new phone number four separate times for testing area code, exchange, station and extension initialization. Create an initialization context, a localized setup that initializes the number and then four separate tests. Voila!<BR/><BR/>Of course, that is a simple case, but I'm finally beginning to see how contexts make sense in a testing scenario. Hey, I'm slow and it only took a year to digest BDD and get bitten by the bug!<BR/><BR/>Cheers,<BR/>Kevinvinbarneshttps://www.blogger.com/profile/02809486041688218244noreply@blogger.comtag:blogger.com,1999:blog-12467669.post-77049375306465312112007-06-11T17:10:00.000-04:002007-06-11T17:10:00.000-04:00This is one case were I think specifications win o...This is one case were I think specifications win over tests. By grouping specs by context, where that context is setup in one place, it's much clearer what is being setup and what's being tested/specified. Sure, you can do the same with tests, but specifications are asking for it.<BR/><BR/>(Better English this time.)Danielhttps://www.blogger.com/profile/06571370918711574297noreply@blogger.comtag:blogger.com,1999:blog-12467669.post-72277264206536582572007-06-11T15:59:00.000-04:002007-06-11T15:59:00.000-04:00Also, I think you're missing part of the point. It...Also, I think you're missing part of the point. It's not that I can't look for a setup method it's that I don't want to have to look for a setup method. Not when I'm creating a new test or looking at one I just found failing. I want to read the test, make the necessary changes and move on. Any additional steps make me less effective.<BR/><BR/>Cheers, JayAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-80005929995438199662007-06-11T15:53:00.000-04:002007-06-11T15:53:00.000-04:00Daniel,Regardless of whether the file is long or i...Daniel,<BR/><BR/>Regardless of whether the file is long or if you use instance variables, setup adds additional complexity to a test file. There's no getting around the fact that extracting a method adds complexity. That's the switch that it's important to make. Instead of thinking in terms of the test suite, think in terms of one test at a time. If your entire application only needed to be 5 lines, would you extract a method? I wouldn't.<BR/><BR/>I can appreciate that we simply disagree on style, but the numbers don't sway my opinion. Both teams from my recent projects were 16 developers large and the assertions were nearing 5k and nearing 7k respectively.<BR/><BR/>I think it's fair to say that the larger the team, the less likely it is that you will be working on your own tests, and the more important it is that there's 0 indirection to follow when fixing a test. Then again, if your team is small enough that you generally work with your own tests, a bit of magic should benefit you.<BR/><BR/>btw, people much smarter than me, such as Dan North, Zak Tamsen, and Christian Taubman led me down this path. It's becoming more and more common as testing practices mature.<BR/><BR/>Cheers, JayAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-41588623665763262152007-06-11T15:39:00.000-04:002007-06-11T15:39:00.000-04:00If the test file is too long? If the programmer kn...If the test file is too long? If the programmer knows the setup method is even executing? These are excuses, not reasons.<BR/><BR/>If your test file is too long, you've got an organizational issue with your tests. It's time to start thinking about splitting out your tests into more manageable chunks. If I have a deep class, I break the tests down into *one file per method*, instead of jamming everything into one monster test file. I've found that keeps things much more mentally manageable.<BR/><BR/>As for "not noticing the setup method is being executed", that is, quite frankly, a pathetic excuse. I don't mean to sound harsh, but you and your colleagues are professional programmers. If a Ruby programmer doesn't immediately recognize an instance variable within a test case as something that's created in a setup method then they have absolutely no business writing tests in the first place. Knowing your tools is a fundamental requirement of using them.<BR/><BR/>I tend to believe that you're thinking in terms of _Rails_ testing, here, though. Because, for example, when I write C extensions I often have to write setup code for cross-platform issues. Typically, this means determining up front whether I'm on MS Windows or not. Sticking that logic in every test would be absurd. I could also go on about how, if you were testing IO objects, there's a good chance your colleagues are going to run your system out of file descriptors at some point, because you didn't have a common teardown method that would do it automatically for you.<BR/><BR/>Now, where I think your article _does_ have merit is, in projects with multiple developers, we must realize that we're not the only ones looking at the test. Our colleagues must understand them as well. I just happen to disagree with the _how_.<BR/><BR/>As for DRYing up your tests, well, after writing over 5,000 tests for an independent Ruby test suite, headed towards 20,000, I can tell you straight up that using a setup method goes a long way towards preserving your wrists...and your sanity. :)Daniel Bergerhttps://www.blogger.com/profile/05224445093970941579noreply@blogger.comtag:blogger.com,1999:blog-12467669.post-70340130790694870582007-06-11T14:31:00.000-04:002007-06-11T14:31:00.000-04:00Sometimes when I read your posts I feel like chant...Sometimes when I read your posts I feel like chanting "His name is Robert Paulsen". It's helpful to think about DRY in the way you've outlined, it's that testing, in a sense, is a similar but parallel world of development.Unknownhttps://www.blogger.com/profile/18445911852488428095noreply@blogger.com