The first discussion (thanks for interresting points of view) about 
tools hasn't ended yet, regardless I have another tool question:

I think many of people use issue-tracking systems. Looking at 
open-source project, they often use it not only to track bugs, but also 
to track feature development.

XP, on the other hand use the notion of acceptance tests to measure the 
progress of development - the more acceptance tests pass, the more the 
software fulfills the customer requirements.

I'm getting an impression, that from time to time the information 
contained in the acceptance test code (and in its javadocs) duplicates 
the information in the issue-tracking system. "Strike two and refactor" 
- I think in that moment.

Have somebody solved the problem of that duplication?

I can imagine writting a tool that would extract the javadocs from 
acceptance test methods, put them as a description on the maven JUnit 
report and generated a separate report showing the progress of 
development in terms of acceptance tests that passed.
    Then, instead of generating a report out of bug-tracking system, 
which has to be manually updated every time something interresting 
happens, the report would constantly show the up-to-date progress of the 
development.

Does somebody know a tool like that?

Przemyslaw Pokrywka

Przemek Pokrywka wrote:

> I'm getting an impression, that from time to time the information 
> contained in the acceptance test code (and in its javadocs) duplicates the 
> information in the issue-tracking system. "Strike two and refactor" - I 
> think in that moment.
>
> Have somebody solved the problem of that duplication?

Yes. Don't run an issue tracking system.

Everyones energies should revolve around placing feature requests, as 
failing tests, into the acceptance test rig.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!! 

Phlip napisa�(a):
> Przemek Pokrywka wrote:
> 
> 
>>I'm getting an impression, that from time to time the information 
>>contained in the acceptance test code (and in its javadocs) duplicates the 
>>information in the issue-tracking system. "Strike two and refactor" - I 
>>think in that moment.
>>
>>Have somebody solved the problem of that duplication?
> 
> 
> Yes. Don't run an issue tracking system.
> 
> Everyones energies should revolve around placing feature requests, as 
> failing tests, into the acceptance test rig.
> 

Hmm... looks promising :)

The acceptance test rig - coming back to the tools - I'm considering 
writing some form of that by myself... but I'm a little affraid, that I 
could end up reinventing the wheel, therefore I'd like to ask about 
tools that are good in that (test rig) role.

Is it always just a JUnit and post-it cards with the stories?
I guess there can exist some tools, which integrate with JUnit and some 
form of stories DB and produce interresting reports.
Does anybody use such tools?

Przemek Pokrywka wrote:

> Is it always just a JUnit and post-it cards with the stories?
> I guess there can exist some tools, which integrate with JUnit and some 
> form of stories DB and produce interresting reports.
> Does anybody use such tools?

Click here:

http://www.zeroplayer.com/cgi-bin/wiki?TestWikiFormat

You write failing acceptance tests as pages in a Wiki. (Here, as failing 
entries in lists on Wiki pages.) This way, the list of features exists in 
one place, a web site, just like an issue database. But you can execute each 
test directly from the web site.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!!

Phlip,

>> I'm getting an impression, that from time to time the information 
>> contained in the acceptance test code (and in its javadocs) duplicates 
>> the information in the issue-tracking system. "Strike two and refactor" - 
>> I think in that moment.
>>
>> Have somebody solved the problem of that duplication?
>
> Yes. Don't run an issue tracking system.

In real-life, this approach is only really feasible on "small" projects, 
which there are many in the world.  However, when large enterprise systems 
are being built by various collaborating development teams it is much easier 
to manage, track and make progress using an issue tracking system.  I am 
currently working on a system that has a domain team, persistence team, 
database team, service team, ui team, system-level test team, 
user-acceptance team, etc.  We have a gazillion unit-tests, an automated and 
continuous build process, automated unit-testing as part of the builds, etc. 
Without the issue tracking system we use, there would be chaos.

> Everyones energies should revolve around placing feature requests, as 
> failing tests, into the acceptance test rig.

It would be nice if real-life were this simplistic in all cases!

Regards,

Randy 

Randy A. Ynchausti wrote:

>> Yes. Don't run an issue tracking system.
>
> In real-life, this approach is only really feasible on "small" projects, 
> which there are many in the world.  However, when large enterprise systems 
> are being built by various collaborating development teams it is much 
> easier to manage, track and make progress using an issue tracking system. 
> I am currently working on a system that has a domain team, persistence 
> team, database team, service team, ui team, system-level test team, 
> user-acceptance team, etc.  We have a gazillion unit-tests, an automated 
> and continuous build process, automated unit-testing as part of the 
> builds, etc. Without the issue tracking system we use, there would be 
> chaos.

It sounds like you don't have the prerequisite - an acceptance test rig that 
makes writing customer tests very easy.

Agreed they would need to be wall-to-wall to replace an issue database...

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!! 

Phlip,

>>> Yes. Don't run an issue tracking system.
>>
>> In real-life, this approach is only really feasible on "small" projects, 
>> which there are many in the world.  However, when large enterprise 
>> systems are being built by various collaborating development teams it is 
>> much easier to manage, track and make progress using an issue tracking 
>> system. I am currently working on a system that has a domain team, 
>> persistence team, database team, service team, ui team, system-level test 
>> team, user-acceptance team, etc.  We have a gazillion unit-tests, an 
>> automated and continuous build process, automated unit-testing as part of 
>> the builds, etc. Without the issue tracking system we use, there would be 
>> chaos.
>
> It sounds like you don't have the prerequisite - an acceptance test rig 
> that makes writing customer tests very easy.

Would you consider a dedicated team that uses FITNESSE interfaced to the 
system through web-services as a qualifying effort for an acceptance test 
rig that makes writing customer tests very easy?  That is what we are doing.

> Agreed they would need to be wall-to-wall to replace an issue database...

We are trying.

Regards,

Randy 

Randy A. Ynchausti wrote:

> Would you consider a dedicated team that uses FITNESSE interfaced to the 
> system through web-services as a qualifying effort for an acceptance test 
> rig that makes writing customer tests very easy?  That is what we are 
> doing.

Natch - you didn't say that.

>> Agreed they would need to be wall-to-wall to replace an issue database...
>
> We are trying.

I have never used such a system in production. How many people use Fitnesse 
to write issues as failing tests. (This is what I have always heard one does 
with it...)

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!!