tag:blogger.com,1999:blog-12467669.post4183004429309787740..comments2023-04-29T07:23:25.825-04:00Comments on Jay Fields' Thoughts: Testing: The Value of Test NamesJayhttp://www.blogger.com/profile/14491442812573747680noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-12467669.post-44514649489003011542009-06-28T06:45:31.634-04:002009-06-28T06:45:31.634-04:00Good answer, I am looking for the solution of the ...Good answer, I am looking for the solution of the same question. Find the movies or mp3 you are looking for at your-download.org the most comprehensive source for free-to-try files downloads on the Webalexiahttps://www.blogger.com/profile/14346599236448023565noreply@blogger.comtag:blogger.com,1999:blog-12467669.post-59624772818543129452008-05-29T18:02:00.000-04:002008-05-29T18:02:00.000-04:00I quite regularly use unnamed specs in rspec. I h...I quite regularly use unnamed specs in rspec. I have a few simple rules for when a spec can (and should) have no explicit description:<BR/><BR/>Only one expectation/assertion is allowed. The code that does it reads very very easily. And the rspec expectation must generate a readable and correct specdoc.<BR/><BR/>And when I leave out the description, I always use <I>specify</I> rather than <I>it</I>, to create the example. I find that <I>it</I> reads very poorly.<BR/><BR/>For example:<BR/><BR/>specify { @it.should reject("").for(:name).with("cannot be blank) }<BR/><BR/>specify { @it.should accept("John Doe").for(:name) }<BR/><BR/>specify { @it.should put_the_lotion_in_the_bucket }<BR/><BR/>specify { @it.should put_the_lotion_in_the_bucket }<BR/><BR/>and so on. (These examples don't match with your testing style of never using setup, but it could certainly be adapted to match that as well.)<BR/><BR/>The ability for rspec matchers to dynamically generate specdoc is one of my favorite aspects of rspec. :-)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-75255199237680964212008-05-29T12:03:00.000-04:002008-05-29T12:03:00.000-04:00Hi Jay, My name is Wei-Ling Chen, I'd like to talk...Hi Jay, <BR/><BR/>My name is Wei-Ling Chen, I'd like to talk to you about our MVB program. Could you shoot me a email at weiling@dzone.com please. <BR/><BR/>Thanks much, look forward to read more on your blog :). <BR/><BR/>Wei-Ling Chen <BR/>weiling@dzone.comAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-84815485243995525312008-05-29T03:26:00.000-04:002008-05-29T03:26:00.000-04:00Not bad idea indeed! I'll try go with your way and...Not bad idea indeed! I'll try go with your way and see how it works with rspec.<BR/><BR/>I looked your examples and they are readable and understandable. I also feel quite often spec descriptions are too noisy for me and prefer to read spec code instead of descriptions.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-64237087261822765622008-05-28T11:05:00.000-04:002008-05-28T11:05:00.000-04:00Dan,I said "I also believe there are other ways to...Dan,<BR/><BR/>I said "I also believe there are other ways to ensure the validity of the system..."<BR/><BR/>I should have stated what I think is a better way.<BR/><BR/>RSpec's story runner is an example of how I think customers are better served by tests. In that case I don't need to show them a description, hopefully they can write the tests themselves, or I can write tests in their domain language.<BR/><BR/>That way the tests written by me for me can be as terse as necessary, and tests written from an acceptance perspective can be written with a domain expert in mind.<BR/><BR/>Thanks again for the comments.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-5123814778635373132008-05-28T10:51:00.000-04:002008-05-28T10:51:00.000-04:00"I don't think that's a argument for comments, it'..."I don't think that's a argument for comments, it's an argument for firing developers that think "z" is an acceptable name for a method."<BR/><BR/>It's a culturally ingrained thing in the APL programming communities. They'd get rid of ASCII characters if they had a chance and every function name would be a unicode character :(<BR/><BR/>http://www.nsl.com/papers/style.pdf (Jump to page 8)<BR/><BR/>"I mentioned that you'd need to consider this when I said you'd lose the ability to use specdoc"<BR/><BR/>Sorry, I must've glossed over that earlier. I read this post right after I got up.<BR/><BR/>"I'm not really a believer in letting the business read descriptions that could be incorrect. I also believe there are other ways to ensure the validity of the system that require less effort from the development team."<BR/><BR/>If the descriptions are incorrect, then you're implying that you have a developer that didn't go to the effort of updating the test descriptions or fixing the test in the first place (that is the test no longer validates the guarantee made or is now superfluous or otherwise incorrect).<BR/><BR/>I just don't think that Intentional code is ever going to be a perfect reality, if only because you'd have to have hard AI to be able to validate intent. Perhaps I came out too strong in my wording earlier (again, I wrote my comment first thing after I'd woken up), because I mostly agree with the general point that code should reflect intent as much as possible. I just think that, especially for something like a test, where you're already double checking your work, it doesn't hurt to double check your meaning (seriously, I can type at like 100wpm. How many words go into a good test description? 8 at the max?)Dan Nugenthttps://www.blogger.com/profile/17024579990613770367noreply@blogger.comtag:blogger.com,1999:blog-12467669.post-26005923051301421122008-05-28T08:33:00.000-04:002008-05-28T08:33:00.000-04:00The point I agree most about is extracting methods...The point I agree most about is extracting methods out of comments.<BR/><BR/>I'm now actually getting accustomed to writing comments with the intent of naming a method after them on later refactorings. So instead of writing a comment like <BR/><BR/>// Assert that inventory quantity in shelf S3 is more than 5<BR/><BR/>I write<BR/><BR/>// bool CheckInventory(Shelf X, int requestedQuantity)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-76629218473612962352008-05-28T06:29:00.000-04:002008-05-28T06:29:00.000-04:00Hi Dan, thanks for your thoughts."you can walk thr...Hi Dan, thanks for your thoughts.<BR/><BR/>"you can walk through the body of a function with a name like z"<BR/><BR/>I don't think that's a argument for comments, it's an argument for firing developers that think "z" is an acceptable name for a method.<BR/><BR/>I also think comments are valuable when used correctly. Step 1 for me is to make the code as clear as possible. Step 2 is to create a comment explaining any why's that the code does not convey. Sometimes I don't get to step 2, but sometimes I do, which is why I left the bit about valuable comments in.<BR/><BR/>"lets take away the big feature that gives business value to spec testing: documenting the guarantees of the program."<BR/><BR/>Why do I need to document the guarantees of the system? Is this a business requirement? Do they read the documents? I've never been in that situation, but if you are then you'll probably not be happy with removing descriptions. I mentioned that you'd need to consider this when I said you'd lose the ability to use specdoc. I'm not really a believer in letting the business read descriptions that could be incorrect. I also believe there are other ways to ensure the validity of the system that require less effort from the development team.<BR/><BR/>I believe Fowler and Beck's assertion that comments generally mark bad code is true. Why else do you need the comment? In some way the code cannot convey enough information so something more (comments) is needed. Sometimes it's unavoidable, but that doesn't remove the fact that comments are still taking the place of what we'd all prefer: code that conveyed intention on it's own.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12467669.post-4772114210527170132008-05-28T06:06:00.000-04:002008-05-28T06:06:00.000-04:00I disagree.I work with Q, a programming language d...I disagree.<BR/><BR/>I work with Q, a programming language descended from APL. People often suggest that comments are unnecessary for Q because of the terseness of the code, but quite often, you can walk through the body of a function with a name like z and have no clue why the hell it exists or what inspired its design choices.<BR/><BR/>You say that comments are unnecessary as a matter of refactoring? I say you'll never get to the step of refactoring if those comments aren't there in the first place, because you'll spend all your time trying to figure out what was in the head of the stupid developer that came before you. One way or another, you're going to need a diligent developer to do his job properly and either update the comments, or update the code artifacts to have as much semantic meaning as possible.<BR/><BR/>I have seen far too many comments about how something works when I can clearly see that, right there in the damn code. No, I still need the why.<BR/><BR/>As for removing test names from specification tests? Yes, terrific idea, lets take away the big feature that gives business value to spec testing: documenting the guarantees of the program.<BR/><BR/>Let me make something clear though, I understand that there is a difference between piles of comments and a few accurately targeted descriptions of what's going on. I spend a lot more time trying to write good variable and function names (we don't have classes) than I do writing comments. But I think that the suggestions that comment existence is in and of itself an indicator of code smell and the corollary that test names are unnecessary are flawed.Dan Nugenthttps://www.blogger.com/profile/17024579990613770367noreply@blogger.com