headers
avi_a | 10 Oct 2011 15:32
Picon
Favicon

Handling several branches of a central product

Hi all.

We have a single product, was developed using ATDD so we have a full suite of  automated acceptance tests for
it (using fitnesse).

Now we need to make a copy or a branch of the product for a new customer.

Assuming we'll be refactoring to reduce duplication between the SUT branches,
what would you do about the acceptance tests?

Currently I can think of 2 ways of going at this:
a) Branch them as well so as to keep two versions of them - one for each customer SUT.
B) Or keep only one version of the tests for a main branch and don't bother testing the branches

(b) doesn't feel right...
Assuming (a) - any ideas as to do this pragmatically with Fitnesse?

Any thoughts or suggestions on this matter would be appreciated.

Avi

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional
(Continue reading)

Permalink | Reply | 28 comments |
headers
Donaldson, John (GEO | 10 Oct 2011 15:43
Picon
Favicon

RE: Handling several branches of a central product

Avi,

Well, I must be answering the wrong question, but here goes:

- create a common branch (or root, or whatever name suits)
- anything which is the same between both customer branches is common and lives in the common branch
- anything which can be parameterized so that it's the same in both branches lives in the common branch
- anything which is specific to a customer lives in the branch for that customer

There's quite a bit of literature these around the idea of "product line engineering" which might apply to
your case.

John D.

-----Original Message-----
From: testdrivendevelopment <at> yahoogroups.com [mailto:testdrivendevelopment <at> yahoogroups.com] On
Behalf Of avi_a <at> mapa.co.il
Sent: 10 October 2011 15:32
To: testdrivendevelopment <at> yahoogroups.com
Subject: [TDD] Handling several branches of a central product

Hi all.

We have a single product, was developed using ATDD so we have a full suite of  automated acceptance tests for
it (using fitnesse).

Now we need to make a copy or a branch of the product for a new customer.

Assuming we'll be refactoring to reduce duplication between the SUT branches,
what would you do about the acceptance tests?
(Continue reading)

Permalink | Reply | 2 comments |
headers
avi_a | 10 Oct 2011 18:51
Picon
Favicon

Re: Handling several branches of a central product

Hi John
Right answer - just to the wrong question :)

I meant what would you suggest to do about the acceptance tests? (fitnesse tests)
Would you make several copies of the tests - one for each customer branch? etc

Since fitnesse uses wikis to manage the tests, it's not as easy to branch them as it is to branch source code,
at least as far as I know...

TIA,
Avi

--- In testdrivendevelopment <at> yahoogroups.com, "Donaldson, John (GEO)" <john.m.donaldson <at> ...> wrote:
>
> Avi,
> 
> Well, I must be answering the wrong question, but here goes:
> 
> - create a common branch (or root, or whatever name suits)
> - anything which is the same between both customer branches is common and lives in the common branch
> - anything which can be parameterized so that it's the same in both branches lives in the common branch
> - anything which is specific to a customer lives in the branch for that customer
> 
> There's quite a bit of literature these around the idea of "product line engineering" which might apply to
your case.
> 
> John D.
> 
> -----Original Message-----
> From: testdrivendevelopment <at> yahoogroups.com [mailto:testdrivendevelopment <at> yahoogroups.com]
(Continue reading)

Permalink | Reply | 1 comment |
headers
Donaldson, John (GEO | 10 Oct 2011 19:11
Picon
Favicon

RE: Handling several branches of a central product

Avi,

I could tell - because the question came from you - that I was not answering the real question. :-)
But anyway, now I have a better idea of the problem.

It would be interesting know how big the problem is: how much overlap do you think there will be between the
two sets of acceptance tests?

If this was TDD and unit tests, we might say: wait until you get the duplication and then remove it. That is, go
ahead and do the copy-paste, but then work to remove the duplication. But I don't have enough experience of
Fitnesse to give you a good answer, I'm afraid.

John D.

-----Original Message-----
From: testdrivendevelopment <at> yahoogroups.com [mailto:testdrivendevelopment <at> yahoogroups.com] On
Behalf Of avi_a <at> mapa.co.il
Sent: 10 October 2011 18:52
To: testdrivendevelopment <at> yahoogroups.com
Subject: Re: [TDD] Handling several branches of a central product

Hi John
Right answer - just to the wrong question :)

I meant what would you suggest to do about the acceptance tests? (fitnesse tests)
Would you make several copies of the tests - one for each customer branch? etc

Since fitnesse uses wikis to manage the tests, it's not as easy to branch them as it is to branch source code,
at least as far as I know...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adam Sroka | 10 Oct 2011 19:18
Picon
Gravatar

Re: Handling several branches of a central product

If I were going to duplicate my whole code base I would duplicate the tests
as well. However, duplicating my whole code base sounds awful enough to me
that I would continue to look for another way.
On Oct 10, 2011 6:32 AM, <avi_a <at> mapa.co.il> wrote:

> **
>
>
> Hi all.
>
> We have a single product, was developed using ATDD so we have a full suite
> of automated acceptance tests for it (using fitnesse).
>
> Now we need to make a copy or a branch of the product for a new customer.
>
> Assuming we'll be refactoring to reduce duplication between the SUT
> branches,
> what would you do about the acceptance tests?
>
> Currently I can think of 2 ways of going at this:
> a) Branch them as well so as to keep two versions of them - one for each
> customer SUT.
> B) Or keep only one version of the tests for a main branch and don't bother
> testing the branches
>
> (b) doesn't feel right...
> Assuming (a) - any ideas as to do this pragmatically with Fitnesse?
>
> Any thoughts or suggestions on this matter would be appreciated.
>
(Continue reading)

Permalink | Reply | 24 comments |
headers
avinap77 | 10 Oct 2011 20:03
Picon
Favicon

Re: Handling several branches of a central product

Adam, John
If I got the same misunderstanding from both of you I must have been  explaining myself wrong..

I'll restate the problem:
I'm going to branch a SUT - there will be no duplication, just branching so the common parts are shared and the
different parts are seperate. This is not my dilemma.

The question is what do you suggest I do with the fitnesse acceptance tests - Would you branch them as well?
(if this is at all technically possible?) 

My problem with these tests is that they don't reside in source-code files like unit tests would, so they
can't be branched together with the SUT.

I've been looking into using symolic links (see Reuse entire suites with symbolic links -
http://gojko.net/FitNesse/book/ch07s03.html) but thought someone might have a solution before I
start reinventing the wheel...

Starting to think I should post this question on the fitnesse or ATDD groups..

Thanks again
Avi

--- In testdrivendevelopment <at> yahoogroups.com, Adam Sroka <adam.sroka <at> ...> wrote:
>
> If I were going to duplicate my whole code base I would duplicate the tests
> as well. However, duplicating my whole code base sounds awful enough to me
> that I would continue to look for another way.
> On Oct 10, 2011 6:32 AM, <avi_a <at> ...> wrote:
> 
> > **
(Continue reading)

Permalink | Reply | 23 comments |
headers
Adam Sroka | 10 Oct 2011 20:09
Picon
Gravatar

Re: Handling several branches of a central product

Yeah, I'm not misunderstanding you I'm just focused on a different part of
the problem than you are, but I will try to help...

There is no easy way that I am aware of to version Fitnesse files. What I
generally do is intialize a git repository where the Fitnesse files are
stored and suspend disbelief about the changes Fitnesse makes when you use
it (I am sure they would make sense if you delved into the internals
sufficiently.)

I have heard other folks claim to have more elegant solutions but I don't
know the details. Perhaps one of them will respond.
 On Oct 10, 2011 11:03 AM, "avinap77" <avi_a <at> mapa.co.il> wrote:

> **
>
>
> Adam, John
> If I got the same misunderstanding from both of you I must have been
> explaining myself wrong..
>
> I'll restate the problem:
> I'm going to branch a SUT - there will be no duplication, just branching so
> the common parts are shared and the different parts are seperate. This is
> not my dilemma.
>
> The question is what do you suggest I do with the fitnesse acceptance tests
> - Would you branch them as well? (if this is at all technically possible?)
>
> My problem with these tests is that they don't reside in source-code files
> like unit tests would, so they can't be branched together with the SUT.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Nayan Hajratwala | 10 Oct 2011 20:21
Gravatar

Re: Handling several branches of a central product

On Oct 10, 2011, at 2:09 PM, Adam Sroka wrote:

> Yeah, I'm not misunderstanding you I'm just focused on a different part of
> the problem than you are, but I will try to help...
> 
> There is no easy way that I am aware of to version Fitnesse files. What I

FitNesse now has built in support for Git and a plugin scheme for other Scms.

	http://fitnesse.org/FitNesse.UserGuide.SourceCodeControl.GitPlugin

> generally do is intialize a git repository where the Fitnesse files are
> stored and suspend disbelief about the changes Fitnesse makes when you use
> it (I am sure they would make sense if you delved into the internals
> sufficiently.)
> 
> I have heard other folks claim to have more elegant solutions but I don't
> know the details. Perhaps one of them will respond.

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
(Continue reading)

Permalink | Reply | 13 comments |
headers
avinap77 | 10 Oct 2011 20:40
Picon
Favicon

Re: Handling several branches of a central product

OK Guys, I just ran into this thread:
http://tech.groups.yahoo.com/group/fitnesse/message/18244

It's basically the same problem I'm having.
I'll be looking into the suggestions they gave there..

Nayan - again, I'm not sure version-control is my issue, but rather maintaining several live versions of my
test suite to support several versions of my SUT - all at the same time, but thanks for the pointer about the
plugin, it might prove useful regardless.

Best wishes,
Avi

--- In testdrivendevelopment <at> yahoogroups.com, Nayan Hajratwala <nayan <at> ...> wrote:
>
> On Oct 10, 2011, at 2:09 PM, Adam Sroka wrote:
> 
> > Yeah, I'm not misunderstanding you I'm just focused on a different part of
> > the problem than you are, but I will try to help...
> > 
> > There is no easy way that I am aware of to version Fitnesse files. What I
> 
> FitNesse now has built in support for Git and a plugin scheme for other Scms.
> 
> 	http://fitnesse.org/FitNesse.UserGuide.SourceCodeControl.GitPlugin
> 
> 
> > generally do is intialize a git repository where the Fitnesse files are
> > stored and suspend disbelief about the changes Fitnesse makes when you use
> > it (I am sure they would make sense if you delved into the internals
(Continue reading)

Permalink | Reply | 12 comments |
headers
Lior Friedman | 10 Oct 2011 21:26
Picon

Re: Handling several branches of a central product

Avi,

What might help is starting to treat your test artifact as you treat source
code artifacts. If you gonna branch the source you probably want to branch
the tests.
Technicaly,( and since i dont know fitness that well this might be wrong),
the branching part is easy, you merging back and forth between the branches
is the real problem.

And last, since at the end fitness is a group of files (or at least the
tests) why cant ghe naive approach of just inserting them into a scmwork?

Lior
On Oct 10, 2011 8:40 PM, "avinap77" <avi_a <at> mapa.co.il> wrote:

> **
>
>
> OK Guys, I just ran into this thread:
> http://tech.groups.yahoo.com/group/fitnesse/message/18244
>
> It's basically the same problem I'm having.
> I'll be looking into the suggestions they gave there..
>
> Nayan - again, I'm not sure version-control is my issue, but rather
> maintaining several live versions of my test suite to support several
> versions of my SUT - all at the same time, but thanks for the pointer about
> the plugin, it might prove useful regardless.
>
> Best wishes,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane