headers
John Maxwell | 10 Feb 02:51
Favicon

Question about a habit/practice

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

--
(Continue reading)

Permalink | Reply |
headers
RonJeffries | 10 Feb 02:55
Picon
Favicon
Gravatar

Re: Question about a habit/practice

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]
Permalink | Reply |
headers
John Maxwell | 10 Feb 03:17
Favicon

Re: Question about a habit/practice

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 <at> toad.net

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.
(Continue reading)

Permalink | Reply |
headers
RonJeffries | 10 Feb 03:25
Picon
Favicon
Gravatar

Re: Question about a habit/practice

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]
Permalink | Reply |
headers
George Dinwiddie | 10 Feb 05:40
Favicon

Re: Question about a habit/practice

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.
(Continue reading)

Permalink | Reply |
headers
M. Manca | 10 Feb 09:10
Picon

Re: Question about a habit/practice

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?
>
(Continue reading)

Permalink | Reply |
headers
Adrian Howard | 10 Feb 15:46
Favicon
Gravatar

Re: Question about a habit/practice


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
(Continue reading)

Permalink | Reply |
headers
George Paci | 13 Feb 00:30
Picon

Re: Question about a habit/practice

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,
(Continue reading)

Permalink | Reply |
headers
Adrian Howard | 14 Feb 06:06
Favicon
Gravatar

Re: Question about a habit/practice

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
(Continue reading)

Permalink | Reply |

Gmane