"Bugs" in Tracker pull incorrectly

[elight]

A Bug, when pulled from Tracker, generates Gherkin with "Bug" where it should have "Feature". This causes Gherkin to error. Workaround is simple.

[tpope]

Yeah, when I first wrote it this way, Cucumber didn't care what came before the colon. I could force it to always do Feature:, but then there's nothing in the file marking it as a bug, and you get #16.

Since I haven't gotten in the habit of making bugs into Cucumber features, I've kind of let this linger. I need a way to mark that a particular story is a bug. Using a @bug tag feels kind of lame because someone could be using that as a label. Any ideas?

[elight]

Thanks for responding, Tim. I'm not ordinarily a cucumber guy but Pickler has become essential to one of my client projects.

What I've done, on some other projects, is have a "regressions" folder under my "integration" test folder. These are almost always acceptance tests because the regressions were usually observed, and described, from a user-facing perspective. I don't see why you (and maybe I should too ;-) ) do the same thing with "features/regressions". With Cuke, it feels a little odd having regressions under features -- but then Cuke sees everything as a "feature".

On Friday, May 13, 2011 at 10:49 PM, tpope wrote:

Yeah, when I first wrote it this way, Cucumber didn't care what came before the colon. I could force it to always do Feature:, but then there's nothing in the file marking it as a bug, and you get #16.

Since I haven't gotten in the habit of making bugs into Cucumber features, I've kind of let this linger. I need a way to mark that a particular story is a bug. Using a @bug tag feels kind of lame because someone could be using that as a label. Any ideas?

Reply to this email directly or view it on GitHub:
#14 (comment)

[tpope]

I don't suppose this has become moot for you in the last 3 months, has it? :) I don't really like the directory idea, but I'm at a loss for better ideas. As you point out, "features/regressions" sounds weird, and does this mean that some features are top level features and others subdirectory features? Or do we move the other features to "features/features"? Ugh.

I'd begrudgingly accept a patch that put bugs under "features/bugs" (I think it's confusing enough without another terminology shift). I'd also accept an @_bug tag. (I hate this idea a little less because if I have a better idea later I don't have to rearrange the user's features.) But I can't say I'm particularly motivated to be the implementer of either.

[elight]

It's moot. We've moved away from using the features (and Cucumber for that matter) as our primary TDD approach.

And thank goodness that to too.

So, sure, close if you like.

On Aug 7, 2011, at 10:25 PM, tpopereply@reply.github.com wrote:

I don't suppose this has become moot for you in the last 3 months, has it? :) I don't really like the directory idea, but I'm at a loss for better ideas. As you point out, "features/regressions" sounds weird, and does this mean that some features are top level features and others subdirectory features? Or do we move the other features to "features/features"? Ugh.

I'd begrudgingly accept a patch that put bugs under "features/bugs" (I think it's confusing enough without another terminology shift). I'd also accept an @_bug tag. (I hate this idea a little less because if I have a better idea later I don't have to rearrange the user's features.) But I can't say I'm particularly motivated to be the implementer of either.

Reply to this email directly or view it on GitHub:
#14 (comment)