tag:blogger.com,1999:blog-1697388841986104302.comments2023-07-02T10:36:44.294-05:00Agile in a FlashAgileotterhttp://www.blogger.com/profile/10773578598860454277noreply@blogger.comBlogger314125tag:blogger.com,1999:blog-1697388841986104302.post-31875569437556364632017-02-09T17:27:58.000-06:002017-02-09T17:27:58.000-06:00var O = l;
var l = 27 * O;
O += l;
var O = l; <br />var l = 27 * O; <br />O += l;<br />Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-14258324941610215532015-08-31T09:20:11.037-05:002015-08-31T09:20:11.037-05:00I remember struggling with some of the things in I...I remember struggling with some of the things in INVEST, and like the shorter VET. Small and negotiable always seemed obvious (or a bit vague) to us in the XP days. Independent is a good addition, though. VITE? VIET?Jeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-12651720872618212012015-08-04T02:27:38.844-05:002015-08-04T02:27:38.844-05:00The original XP take on what made a good story was...The original XP take on what made a good story was that it had to have business value, it had to be estimable, and it had to be testable. That might have made for a simpler and also appropriate acronym, VET. <a href="http://www.zirra.com/iop/ascenergy-2/" rel="nofollow">Ascenergy</a>Elizabeth J. Nealhttps://www.blogger.com/profile/01824134730760179008noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-71913673347152128752015-06-06T05:46:13.143-05:002015-06-06T05:46:13.143-05:00I love Comic-Sans. Ignore the text-trolls!I love Comic-Sans. Ignore the text-trolls!Anonymoushttps://www.blogger.com/profile/01565986400527688704noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-78149127997816940382015-05-21T08:03:31.707-05:002015-05-21T08:03:31.707-05:00Hi Tim and Jeff. Thanks for this nice article. We ...Hi Tim and Jeff. Thanks for this nice article. We figured out that standup meetings are great but<br />needed improvement (they took a lot of time, de-focussed our colleagues and<br />interrupted their workflows). Because of this we developed a SaaS tool to ʺautomateʺ the daily standupmeetings - with just a single email. If you like to take a look: www.30secondsmail.com.<br />Best, Revino<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-16778266911809073662014-01-21T15:48:59.706-06:002014-01-21T15:48:59.706-06:00I appreciate Weinberg's book. His stories cal...I appreciate Weinberg's book. His stories calmed me. I now know others share similar experiences. He is not cynical, instead his clarity offers a very lucid human view of the world.Art Joneshttps://www.blogger.com/profile/15935156561834649507noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-72332083485558358732013-10-19T06:51:43.245-05:002013-10-19T06:51:43.245-05:00There are many principles that guide Software Tes...There are many principles that guide <a href="http://testinginterviewsquestions.blogspot.com/2012/10/software-testing-principle.html" rel="nofollow"> Software Testing Principle</a>. Before applying methods to design effective test cases, a software engineer must understand the basic principles that guide software testing. The following are the main principles for testing Jagran Todayhttps://www.blogger.com/profile/13923216129405273369noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-10838994031949985092013-03-13T10:12:18.136-05:002013-03-13T10:12:18.136-05:00"We learn from our mistakes, we learn from th..."We learn from our mistakes, we learn from the examples set by others. We learn from books and blogs and webinars, from magic beans and electric parsnips."<br /><br />It means from any source at all, even those unlikely or absurd. Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-30594072842392929972013-03-13T04:12:52.819-05:002013-03-13T04:12:52.819-05:00I have absolutely no idea what you mean by "m...I have absolutely no idea what you mean by "magic beans and electric parsnips". Would you please explain? Thanks.<br /><br />-- Günter.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-76570754608076486882013-03-10T05:34:45.622-05:002013-03-10T05:34:45.622-05:00Card-carrying embedded-software engineer James Gre...Card-carrying embedded-software engineer James Grenning, fellow-author, fellow-ex-ObjectMentor consultant, owner of Renaissance Software, great guy. Here James shows off his deck of cards at a Starbucks near Mundelein, IL. Doing embedded software, but don't know how to do it test-first? See James Grenning (and buy his book Test Driven Development for Embedded C to be released very soon). <a href="http://www.automateandvalidate.com" rel="nofollow">click here</a>Anonymoushttps://www.blogger.com/profile/03844073281607603842noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-40195445935041104382012-12-26T17:50:05.922-06:002012-12-26T17:50:05.922-06:00You know, here on the blog (and our personal blogs...You know, here on the blog (and our personal blogs, and the IL blog) we're giving ideas away for free. I hope there are a lot of people using the ideas they get here, and I don't mind overly much if they don't remember where they got them. <br /><br />A little fame for an author is a nice thing. But we didn't invent everything we know either, and lord knows if we will ever remember where we got it all. We try to be good about it, but heck we see stuff copied. <br /><br />We see a lot of people "pirating" the book, too. It's something that happens, and certainly full-blown copyright infringement is more upsetting and actionable, but if any particular idea finds its way from the blog or book into the world where it helps someone then we're pretty darned happy.Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-55010196627655317452012-12-26T14:46:29.266-06:002012-12-26T14:46:29.266-06:00I hope so.I hope so.Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-67476643350274220982012-06-25T15:56:00.824-05:002012-06-25T15:56:00.824-05:00We've received a number of entries and have se...We've received a number of entries and have selected winners. We're notifying the winners now and will put together a blog post for a few weeks out.Jeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-45985956669278233492012-06-05T20:36:19.537-05:002012-06-05T20:36:19.537-05:00Cool idea!Cool idea!George Dinwiddiehttp://blog.gdinwiddie.comnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-5529997423156076972012-05-25T02:02:55.120-05:002012-05-25T02:02:55.120-05:00This comment has been removed by a blog administrator.Himashu shouhttps://www.blogger.com/profile/13821457266766165133noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-82578398874436346522012-05-21T13:24:19.050-05:002012-05-21T13:24:19.050-05:00See also this article: http://www.forbes.com/sites...See also this article: http://www.forbes.com/sites/stevedenning/2012/04/17/the-case-against-agile-ten-perennial-management-objections/<br /><br />I have some differences of opinion or presentation choice, but I think there's a lot of real-life exposure in the article.Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-62170456291348179052012-05-16T07:46:46.971-05:002012-05-16T07:46:46.971-05:00Yes they are essential! I view good naming as one ...Yes they are essential! I view good naming as one of the most important things you can focus on. Like with everything else "agile," you visit it initially, invest a bit of time, revisit it when you think you're ready to move on (commit/push your code), and reconsider it yet again down the road when you see it again.Jeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-20992737811449451012012-05-16T07:15:34.117-05:002012-05-16T07:15:34.117-05:00In some particular situations, clients or some spe...In some particular situations, clients or some specialists in their company want to get access to your unit test. In one of my project, I had to produce human-readable documents from unit and integration tests. Good test names was essential.Dave Couturehttps://www.blogger.com/profile/16394841322477258308noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-4059854350786926742012-05-15T19:49:50.360-05:002012-05-15T19:49:50.360-05:00At least one tweeter thought this card represented...At least one tweeter thought this card represented "horrible" advice. I know it's hard for people to get past an initial (purposefully) contentious statement.<br /><br />Revisiting your test names is actually very important advice that works very well in practice.<br /><br />What truly matters is end product. Not the thought process involved in its creation, and not the order in which things were created. The test name itself, and the meaning it bestows on the next developer that must understand the test, is extremely important. And I do mean extremely.<br /><br />Yes: Most of the time you should know what you are test-driving. You might even want to consider working backward from an end goal ("write assertions first"), because it can help you write the test as more a declaration of intent, instead of a progression of step implementations. That's a suggestion. Try it. If it helps you, that's great, and if not, don't feel other dogmatic folks make you feel bad about not working that way.<br /><br />Anyone who's coded extensively has found times when they needed to explore. "I know roughly what I need to do, and I think I know how to accomplish that, but I'm not sure precisely how to express it." Or: "I know the steps I need to take to accomplish my goal, but I'm not sure how to express those in a more abstract sense." Either way, you could sit and debate names for five minutes, ten minutes, or maybe more, before you coded anything. Or you could sketch out what you think needs to happen, get it to work, and revisit what you really thought you were doing.<br /><br />Never be blocked! TDD can allow you to probe at an appopriate direction for the system, them refine the definition of that notion once it appears to be what you're looking for.<br /><br />A test name need not be perfect before you begin coding. In fact, I find any such "rule" against the spirit of agile and more in the realm of analysis paralysis. We accept that up-front design can never be perfect or complete, so why would we insist on the same fallacy for test names?<br /><br />Better: Accept that you can come up with a pretty darn good name in quick order. Realize there will be important learning as you implement the test. Finally, admit your original test name might not have been perfect, and fix it.<br /><br />Our problem is not the thinking process people use to arrive at a solution. It is that they are unwilling to shed their hubris (or laziness, or whatever) and admit that there might be an even better one.Jeff Langrhttps://www.blogger.com/profile/10499693020049210645noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-13859160129802048022012-05-15T13:31:57.481-05:002012-05-15T13:31:57.481-05:00What kind of detail would you like?
Our intent is...What kind of detail would you like?<br /><br />Our intent is to provide some guidelines to help your team produce the standard they want (or need) so they can get more work done. These really do seem to be the right steps. I suppose my next team could outline their progress through the steps.<br /><br />If you are looking for some existing standards to start from, we could post a few.<br /><br />I'll look into getting a story with examples together.Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-39237129983048313762012-05-15T09:07:24.046-05:002012-05-15T09:07:24.046-05:00@Anonymous:
The test name is 1/3rd of the picture...@Anonymous:<br /><br />The test name is 1/3rd of the picture. The fixture name, the test name, and the assert together are descriptive. "Expected exception not thrown in MapInsertions.rejectsDuplicate()" means that "rejectsDuplicate" is a fine name.<br /><br />Also realize that the context includes the other tests. If you look at the list of tests, then any one test becomes _more_ meaningful. <br /><br />This way we can have the virtues of uniqueness and terseness in our naming... eventually. In the mean time, a big long test name is just fine.Agileotterhttps://www.blogger.com/profile/10773578598860454277noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-75804523193752533232012-05-15T08:31:17.258-05:002012-05-15T08:31:17.258-05:00You need an example.
it "should create a g...You need an example.<br /><br /> it "should create a graph containing the current Post's title" do<br /> post = posts(:Jammin)<br /> map = MindMap.new(post)<br /> dot = map.to_dot<br /> dot.should match(/graph mind_map \{/)<br /> dot.should match(/post_#{post.id}.*label = .#{post.title}/)<br /> end<br /><br />http://broadcast.oreilly.com/2009/02/merb-mind-maps.html<br /><br />Now note that test names (and, uh, "spec" names) don't need Programmer-Speak. They can be complete sentences, because they should rarely be called directly. And modern test runners can use real strings, not function names, as test names.Unknownhttps://www.blogger.com/profile/06139892472117483946noreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-23434149959790885992012-05-15T08:21:29.337-05:002012-05-15T08:21:29.337-05:00Some examples would be helpful to illustrate the p...Some examples would be helpful to illustrate the point. All of these are for the same test case.<br /><br />test0() <-- no lie, i actually saw this as a test name<br /><br />badInsert() <-- better, but still not capturing intent<br /><br />coverErrorPath() <-- ick, not much better than test0<br /><br />ensureUniquenessByRejectingInsertionOfDuplicate() <-- aaaahhhhAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-21092444022467884122012-05-15T06:26:21.514-05:002012-05-15T06:26:21.514-05:00Great article!
One thing I would add to this is &...Great article!<br /><br />One thing I would add to this is "Don't be worried about length when naming your tests...just be clear!"<br /><br />Having done a lot of mentoring on TDD I have come across an aversion to long method names and although I agree with this, somewhat, in non-test methods I urge people to be as descriptive as possible when naming tests. At a glance someone should be able to read the signature of a test method and know exactly what is being tested and more importantly know exactly why the test would fail.KBurnellhttp://www.dotnetdevdude.comnoreply@blogger.comtag:blogger.com,1999:blog-1697388841986104302.post-9703613318446262202012-05-01T14:20:41.325-05:002012-05-01T14:20:41.325-05:00I expanded this comment into a blog post: http://b...I expanded this comment into a blog post: http://blog.orfjackal.net/2012/05/unit-test-focus-isolation.htmlEsko Luontolahttps://www.blogger.com/profile/03956946511109435404noreply@blogger.com