Loading ...
Sorry, an error occurred while loading the content.

Question about a habit/practice

Expand Messages
  • John Maxwell
    I have a habit (Might even rise to the status of a practice. At the very least, it s a pattern, or perhaps anti-pattern) that I d like to hear thoughts on.
    Message 1 of 9 , Feb 9, 2012
    • 0 Attachment
      I have a habit (Might even rise to the status of a practice. At the
      very least, it's a pattern, or perhaps anti-pattern) that I'd like to
      hear thoughts on.

      Fairly often (say, a few times per week), when I'm working on making a
      unit test pass, I find that a change elsewhere in the code is necessary
      in order to implement what I'm working on.

      I'm not talking about noticing something unrelated that needs doing; in
      that case, it just goes onto my ToDo list, and I proceed with the task
      at hand.

      I mean that a previously implemented piece of code that relates to the
      one I'm working on needs to behave differently than I thought when I
      wrote its unit test and implemented it.

      Further, I'm talking about a change that's significant enough to
      warrant writing a new unit test (or sometimes even a few).

      My habit, in such cases, is to mark the current tests "pending" (Or
      just comment it out, if the test framework I'm using doesn't have that
      capability. Boo on test frameworks that don't.), go and make the
      change in the related code in a TDD fashion, then return to my original
      task.

      Thoughts? Comments? Flames?

      -John

      --
      John Maxwell KB3VLL jmax@...

      Microsoft is a cross between The Borg and the Ferengi. Unfortunately
      they use Borg to do their marketing and Ferengi to do their
      programming.
      -Simon Slavin
    • RonJeffries
      Hi John, ... Sure, why not. Or, I might just make the existing test work, which will require the change in question. Then I decide whether a closer-in test is
      Message 2 of 9 , Feb 9, 2012
      • 0 Attachment
        Hi John,

        On Feb 9, 2012, at 8:51 PM, John Maxwell wrote:

        > My habit, in such cases, is to mark the current tests "pending" (Or
        > just comment it out, if the test framework I'm using doesn't have that
        > capability. Boo on test frameworks that don't.), go and make the
        > change in the related code in a TDD fashion, then return to my original
        > task.


        Sure, why not. Or, I might just make the existing test work, which will require the change in question. Then I decide whether a closer-in test is needed on the related code.

        Ron Jeffries
        www.XProgramming.com
        If another does not intend offense, it is wrong for me to seek it;
        if another does indeed intend offense, it is foolish for me to permit it.
        -- Kelly Easterley



        [Non-text portions of this message have been removed]
      • John Maxwell
        ... Well, I don t see why not either, but since I d never seen such a thing mentioned in any prior descripton of the TDD workflow, I thought it was worth at
        Message 3 of 9 , Feb 9, 2012
        • 0 Attachment
          On 02/09/2012 08:55:08 PM, RonJeffries wrote:

          > Sure, why not.
          Well, I don't see why not either, but since I'd never seen such a thing
          mentioned in any prior descripton of the TDD workflow, I thought it was
          worth at least a little discussion. I'm not real stressed out or
          worried over it.

          > Or, I might just make the existing test work, which
          > will require the change in question. Then I decide whether a closer-
          > in
          > test is needed on the related code.

          Totally true, and exactly what I do many times. Here, I'm more talking
          about the case where the change to the related code is significant
          enough that not having a direct test for it first makes me
          uncomfortable.

          -John

          --
          John Maxwell KB3VLL jmax@...

          Adulthood isn't an award they'll give you for being a good child. You
          can waste... years, trying to get someone to give that respect to you,
          as though it were a sort of promotion or raise in pay. If only you do
          enough, if only you are good enough. No. You have to just... take
          it. Give it to yourself, I suppose. Say, I'm sorry you feel like that
          and walk away. But that's hard.

          -Lois McMaster Bujold, A Civil Campaign, 1999
        • RonJeffries
          Hi John, ... Sure. Actually I think most of the TDD books talk about marking a test ignored, working on something else, then unignoring ... Ron Jeffries
          Message 4 of 9 , Feb 9, 2012
          • 0 Attachment
            Hi John,

            On Feb 9, 2012, at 9:17 PM, John Maxwell wrote:

            > Totally true, and exactly what I do many times. Here, I'm more talking
            > about the case where the change to the related code is significant
            > enough that not having a direct test for it first makes me
            > uncomfortable.


            Sure. Actually I think most of the TDD books talk about marking a test ignored, working on something else, then unignoring ...

            Ron Jeffries
            www.XProgramming.com
            If it is more than you need, it is waste. -- Andy Seidl



            [Non-text portions of this message have been removed]
          • George Dinwiddie
            John, ... Yes, I ve noticed that on occasion. Sometimes it drives me slightly nuts, as it can lead to a rather long deviation from the current goal. ... I
            Message 5 of 9 , Feb 9, 2012
            • 0 Attachment
              John,

              On 2/9/12 8:51 PM, John Maxwell wrote:
              > I have a habit (Might even rise to the status of a practice. At the
              > very least, it's a pattern, or perhaps anti-pattern) that I'd like to
              > hear thoughts on.
              >
              > Fairly often (say, a few times per week), when I'm working on making a
              > unit test pass, I find that a change elsewhere in the code is necessary
              > in order to implement what I'm working on.
              >
              > I'm not talking about noticing something unrelated that needs doing; in
              > that case, it just goes onto my ToDo list, and I proceed with the task
              > at hand.
              >
              > I mean that a previously implemented piece of code that relates to the
              > one I'm working on needs to behave differently than I thought when I
              > wrote its unit test and implemented it.

              Yes, I've noticed that on occasion. Sometimes it drives me slightly
              nuts, as it can lead to a rather long deviation from the current goal.

              > Further, I'm talking about a change that's significant enough to
              > warrant writing a new unit test (or sometimes even a few).
              >
              > My habit, in such cases, is to mark the current tests "pending" (Or
              > just comment it out, if the test framework I'm using doesn't have that
              > capability. Boo on test frameworks that don't.), go and make the
              > change in the related code in a TDD fashion, then return to my original
              > task.

              I prefer to start more with the primary functionality rather than the
              lower-level supporting functionality. Then I can fake the supporting
              functionality until I'm ready to drive it with tests, or start building
              it in place and bud it off to its proper spot.

              The point is, by the time I get to the lower-level functionality, I have
              a better picture of the API and behavior than I did if I created the
              lower-level first. It also lets me work in smaller steps.

              Of course, I don't do /anything/ completely consistently, but I'm
              generally happier (and so is the code) when I work down from the top
              like that.

              - George

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • M. Manca
              ... I work in the same way some times. Some times also I find that a previously tested piece of software has inside a common part of software I am writing so I
              Message 6 of 9 , Feb 10, 2012
              • 0 Attachment
                Il 10/02/2012 02:51, John Maxwell ha scritto:
                >
                >
                > I have a habit (Might even rise to the status of a practice. At the
                > very least, it's a pattern, or perhaps anti-pattern) that I'd like to
                > hear thoughts on.
                >
                > Fairly often (say, a few times per week), when I'm working on making a
                > unit test pass, I find that a change elsewhere in the code is necessary
                > in order to implement what I'm working on.
                >
                > I'm not talking about noticing something unrelated that needs doing; in
                > that case, it just goes onto my ToDo list, and I proceed with the task
                > at hand.
                >
                > I mean that a previously implemented piece of code that relates to the
                > one I'm working on needs to behave differently than I thought when I
                > wrote its unit test and implemented it.
                >
                > Further, I'm talking about a change that's significant enough to
                > warrant writing a new unit test (or sometimes even a few).
                >
                > My habit, in such cases, is to mark the current tests "pending" (Or
                > just comment it out, if the test framework I'm using doesn't have that
                > capability. Boo on test frameworks that don't.), go and make the
                > change in the related code in a TDD fashion, then return to my original
                > task.
                >
                > Thoughts? Comments? Flames?
                >
                I work in the same way some times. Some times also I find that a
                previously tested piece of software has inside a common part of software
                I am writing so I stop to do it, make a little refactoring on the
                existent part assuring that it pass unit tests and then I use the common
                part on the new piece of software I was writing. When unit test
                framework doesn't support pending I leave it to fail, this is the only
                difference I note from you.
                >
                >
                > -John
                >
                > --
                > John Maxwell KB3VLL jmax@... <mailto:jmax%40toad.net>
                >
                > Microsoft is a cross between The Borg and the Ferengi. Unfortunately
                > they use Borg to do their marketing and Ferengi to do their
                > programming.
                > -Simon Slavin
                >
                >



                [Non-text portions of this message have been removed]
              • Adrian Howard
                On 10 Feb 2012, at 01:51, John Maxwell wrote: [snip] ... [snip] I have done this and don t see there being any problem with it (assuming that the pending test
                Message 7 of 9 , Feb 10, 2012
                • 0 Attachment
                  On 10 Feb 2012, at 01:51, John Maxwell wrote:
                  [snip]
                  > My habit, in such cases, is to mark the current tests "pending" (Or
                  > just comment it out, if the test framework I'm using doesn't have that
                  > capability. Boo on test frameworks that don't.), go and make the
                  > change in the related code in a TDD fashion, then return to my original
                  > task.
                  >
                  > Thoughts? Comments? Flames?
                  [snip]

                  I have done this and don't see there being any problem with it (assuming that the pending test actually does get fixed - I've left them floating for too long on occasion).

                  Something else I've done fairly often is just delete the failing test, and go off and fix the related code. The next test to write is usually obvious, and it stops pending tests building up if I get distracted or have to focus on something else for a bit. I also find that the failing test often gets rewritten anyway after the diversion is complete.

                  Currently I more often reach to my source control system and checkout a fresh version of trunk, fix the related code, then return to my original code and merge the changes in. I do this for a few reasons:

                  * it's not any harder than the test ignoring/deleting option (For certain source control software anyway. I wouldn't want to do it in CVS)

                  * I find it hard to predict how long the diversion in the related code is going to take, and I prefer to keep the lifetime of pending tests to be short since they often turn from "pending" to "wrong" if I'm not paying attention.

                  * As I mentioned before I often discover that after I've finished the diversion I want to rewrite the failing test too so keeping it around is a waste anyway, so I just end up discarding the pending test.

                  Cheers,

                  Adrian
                  --
                  http://quietstars.com adrianh@... twitter.com/adrianh
                  t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh
                • George Paci
                  ... I think I know what you re saying here, but just to be sure: Trunk is at state T0; call the module you re working in Module A. You add a test, add some
                  Message 8 of 9 , Feb 12, 2012
                  • 0 Attachment
                    On 2/10/12 9:46 AM, Adrian Howard wrote:
                    > On 10 Feb 2012, at 01:51, John Maxwell wrote:
                    > [snip]
                    >> My habit, in such cases, is to mark the current tests "pending" (Or
                    >> just comment it out, if the test framework I'm using doesn't have that
                    >> capability. Boo on test frameworks that don't.), go and make the
                    >> change in the related code in a TDD fashion, then return to my original
                    >> task.
                    >>
                    >> Thoughts? Comments? Flames?
                    > [snip]
                    >
                    > I have done this and don't see there being any problem with it (assuming that the pending test actually does get fixed - I've left them floating for too long on occasion).
                    >
                    > Something else I've done fairly often is just delete the failing test, and go off and fix the related code. The next test to write is usually obvious, and it stops pending tests building up if I get distracted or have to focus on something else for a bit. I also find that the failing test often gets rewritten anyway after the diversion is complete.
                    >
                    > Currently I more often reach to my source control system and checkout a fresh version of trunk, fix the related code, then return to my original code and merge the changes in.

                    I think I know what you're saying here, but just to be sure:

                    Trunk is at state T0; call the module you're working in
                    Module A. You add a test, add some code to make it green,
                    refactor; call your working directory's state T1.

                    Then you add another test, but in order to make it green,
                    you have to change some other code somewhere (call it Module
                    B), in a way that warrants one or more new unit tests.
                    Call the state of your working directory with the red test T2.

                    You use version control to stash state T2, go to state T0,
                    and continue working to add the new unit test for Module B
                    and add the code to make it pass (and refactor).
                    Call the state of the working directory now T3.

                    Then you use your version control system to merge T3 and T2
                    together (call it T5, to avoid confusion). Now you're in a
                    state where the Module B work is done, and your Module A
                    test actually might pass (if the change in Module B was all
                    it needed). Either way, you continue working: refactor, add
                    another test, make it pass....

                    Is this what you meant? Or instead of going back to T0, do
                    you go back to T1?

                    > I do this for a few reasons:
                    >
                    > * it's not any harder than the test ignoring/deleting option (For certain source control software anyway. I wouldn't want to do it in CVS)
                    >
                    > * I find it hard to predict how long the diversion in the related code is going to take, and I prefer to keep the lifetime of pending tests to be short since they often turn from "pending" to "wrong" if I'm not paying attention.
                    >
                    > * As I mentioned before I often discover that after I've finished the diversion I want to rewrite the failing test too so keeping it around is a waste anyway, so I just end up discarding the pending test.

                    It seems like one salient advantage of using version control
                    like this is that work on Module B can happen without being
                    complicated by the changes made to Module A (if you go all
                    the way back to T0). But how often does such complication
                    really happen?

                    I use stash in git all the time, but I never thought about
                    using it for this kind of case. Typically, to mark a test
                    Pending, I prefix the name with "XXXXXXXXXXXXX", which (a)
                    is not picked up as a test by the framework and (b) is
                    pretty hard to miss in the diff I look over before I commit.

                    I never thought about having many Pending tests; it seems
                    like it would be difficult to build up a pile of them
                    without doing something else very wrong. Or, you know,
                    having a development situation that hasn't occurred in my
                    limited experiences.

                    But maybe Sorites was onto something with his paradox[1]:
                    maybe even one Pending test is a pile, and should be
                    avoided: like a comment, it can quickly become out-of-date.

                    --George

                    [1] http://en.wikipedia.org/wiki/Sorites_paradox
                    PS: Just in case Prof. Fine is reading this: I'm kidding about
                    Sorites being a person.
                  • Adrian Howard
                    Hi George, On 12 Feb 2012, at 23:30, George Paci wrote: [snip] ... [expansion snipped] Yup - that s it :) [snip] ... For me it s not so much that the changes
                    Message 9 of 9 , Feb 13, 2012
                    • 0 Attachment
                      Hi George,

                      On 12 Feb 2012, at 23:30, George Paci wrote:
                      [snip]
                      >> Currently I more often reach to my source control system and checkout a fresh version of trunk, fix the related code, then return to my original code and merge the changes in.
                      >
                      > I think I know what you're saying here, but just to be sure:
                      [expansion snipped]

                      Yup - that's it :)

                      [snip]
                      > It seems like one salient advantage of using version control
                      > like this is that work on Module B can happen without being
                      > complicated by the changes made to Module A (if you go all
                      > the way back to T0). But how often does such complication
                      > really happen?

                      For me it's not so much that the changes to A complicate B, but that the changes to B can affect the direction taken with A.

                      Especially in the early stages I'm discovering the design with TDD. The changes to B might lead me to other changes in C and so on. By the time I come up from that rabbit hole the direction originally taken with A may turn out to be wrong.

                      > I use stash in git all the time, but I never thought about
                      > using it for this kind of case. Typically, to mark a test
                      > Pending, I prefix the name with "XXXXXXXXXXXXX", which (a)
                      > is not picked up as a test by the framework and (b) is
                      > pretty hard to miss in the diff I look over before I commit.

                      I use TODO tests in my framework (TAP based) which means that they show up as passing/failing, but a "fail" doesn't cause an overall failure in the test suite, and a "pass" gives an "unexpected success" message.

                      > I never thought about having many Pending tests; it seems
                      > like it would be difficult to build up a pile of them
                      > without doing something else very wrong. Or, you know,
                      > having a development situation that hasn't occurred in my
                      > limited experiences.

                      I think "doing something else very wrong" is a good way of describing what happened with me on occasions where multiple pending tests build up :-) Using the stash gives me a bit of discipline to stop making the same mistakes again.

                      > But maybe Sorites was onto something with his paradox[1]:
                      > maybe even one Pending test is a pile, and should be
                      > avoided: like a comment, it can quickly become out-of-date.

                      That's pretty much my opinion. About the only time I use pending tests now are for things that I can't fix immediately (problems caused by third party code for example).

                      Cheers,

                      Adrian
                      --
                      http://quietstars.com adrianh@... twitter.com/adrianh
                      t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh
                    Your message has been successfully submitted and would be delivered to recipients shortly.