Home > Archive > Extreme Programming > November 2005 > Refactoring the toolbox?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Refactoring the toolbox?
|
|
| Przemek Pokrywka 2005-11-07, 9:58 pm |
| 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
[url]http://www.greencheese.org/Z Land[/url] <-- NOT a blog!!!
| |
| Przemek Pokrywka 2005-11-07, 9:58 pm |
| Phlip napisał(a):
> Przemek Pokrywka wrote:
>
>
>
>
> 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
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
| Randy A. Ynchausti 2005-11-07, 9:58 pm |
| 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.
> 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:
>
> 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
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
| Randy A. Ynchausti 2005-11-07, 9:58 pm |
| Phlip,
>
> 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.
>
> 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
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
|
|
|
|
|