Idea: OFBiz self-hosting

[Bruno Busco]

Thinking more on the subject...
something we could do is to have a NEW web site ofbiz-hosted intended for
(new) specific tasks.

I am thinking for example to a web site where the user contributed visual
themes can be uploaded, reviewed and tested using the selectable visual
theme feature (when it will be committed).
I am inventing nothing, I am writing about something similar to
http://themegarden.org/drupal6/

We could also go further introducing a section where code snippets are
hosted and commented.
Even an online help section could be a good subject; this could be somehow
exported and mounted in local ofbiz installation (being based on ofbiz cms
and not Confluence).

But again I feel it will be greatly beneficial that developers share an
ofbiz installation to work on, not just a demo.
I am slowly starting to use the CMS and many improvement needs jump in my
eyes but I am not sure everybody can see them because they come form a
real-world cms use.

My two cents,
-Bruno

2008/9/4 David E. Jones <[hidden email]>

>
> Not Adam Heath obviously... ;)
>
> -David
>
>
>
> BJ Freeman wrote:
>
>> Just out of curiosity, who funds all this infrastructure?
>>
>> Adam Heath sent the following on 9/3/2008 9:17 PM:
>>
>>> Christian Geisert wrote:
>>>
>>>> Bruno Busco schrieb:
>>>>
>>>>> I agree with you all that OFBiz, being part of Apache, should follow
>>>>> the
>>>>> standard and use their infra and tools.
>>>>>
>>>> Actually there is no standard - Some projects are using Confluence,
>>>> others Forrest or Anakia, some even Maven. AFAIK the only requirement
>>>> from Infra is that the actual served pages are static. For example
>>>> the Lenya project recently started to manage their website with Lenya
>>>> itself (basicly running Lenya in a zone and exporting the html pages,
>>>> see http://lenya.apache.org/docu/website-update.html for details)
>>>>
>>> Static?  WTH?  Seriously?  That's fucked.
>>>
>>> If your main product that you sell is producing dynamic database pages,
>>> but you can't even run your own site in it, then why would I want to buy
>>> your product in the first place?
>>>
>>> Now, I do understand that at some volumes, you need to switch to static;
>>> but then there should be an automated framework(oh, I don't know, maybe
>>> some automated front-end reverse cache or something, maybe there is even
>>> some apache software that can already do this, possibly).  But to
>>> *require* sites to *only* be static, now that's just insane.
>>>
>>>
>>>
>>>
>>

[Enrique Ruibal]

I think too that Ofbiz CMS should be leveraged to:

- Provide Online Help to Ofbiz power users
- Host the Main Ofbiz project Site in different languages
- Provide a separate demo site to showcase specific CMS features such as visual themes and running snippets, just like already there is one for ecommerce and another one for the  backoffice apps.

My 2 cents.

Regards,

Enrique Ruibal

[Jacques Le Roux]

From: "Enrique Ruibal" <[hidden email]>
> I think too that Ofbiz CMS should be leveraged to:
>
> - Provide Online Help to Ofbiz power users

Try the help button on https://demo.hotwaxmedia.com/projectmgr/control/main

> - Host the Main Ofbiz project Site in different languages

As always... Manpower...

> - Provide a separate demo site to showcase specific CMS features such as
> visual themes and running snippets, just like already there is one for
> ecommerce and another one for the  backoffice apps.

Good idea, looking forward for patches ;o)

Jacques

> My 2 cents.
>
> Regards,
>
> Enrique Ruibal
>
> --
> View this message in context: http://www.nabble.com/Idea%3A-OFBiz-self-hosting-tp19235405p19487769.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

[Bruno Busco]

...it seems time is mature now ... ;-)

-Bruno

2008/9/15 Jacques Le Roux <[hidden email]>

> From: "Enrique Ruibal" <[hidden email]>
>
>> I think too that Ofbiz CMS should be leveraged to:
>>
>> - Provide Online Help to Ofbiz power users
>>
>
> Try the help button on
> https://demo.hotwaxmedia.com/projectmgr/control/main
>
>  - Host the Main Ofbiz project Site in different languages
>>
>
> As always... Manpower...
>
>  - Provide a separate demo site to showcase specific CMS features such as
>> visual themes and running snippets, just like already there is one for
>> ecommerce and another one for the  backoffice apps.
>>
>
> Good idea, looking forward for patches ;o)
>
> Jacques
>
>
>  My 2 cents.
>>
>> Regards,
>>
>> Enrique Ruibal
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Idea%3A-OFBiz-self-hosting-tp19235405p19487769.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>
>>

[Enrique Ruibal]

Hello Bruno,

What do you have in mind?, Is there something that can be started on your end?

How Can I help with Testing / Documenting stuff?

Regards,

Enrique R.

[Bruno Busco]

Hi Enrique,
I just bumped this thread up because using OFBiz itself in place of
Confluence and even Jira has been discussed in the Apache Symposium
(according to David's notes).

I think that setting a server up and running is something HWM will do
something about.
On my end I will more than happy to help this happen and kept running.

-Bruno


2008/11/13 Enrique Ruibal <[hidden email]>

>
> Hello Bruno,
>
> What do you have in mind?, Is there something that can be started on your
> end?
>
> How Can I help with Testing / Documenting stuff?
>
> Regards,
>
> Enrique R.
>
> --
> View this message in context:
> http://www.nabble.com/Idea%3A-OFBiz-self-hosting-tp19235405p20471724.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
>

[David E Jones-3]

Actually as we get OFBiz ready to run for OFBiz we'll have it hosted  
on ASF infra. The OFBiz resources that are not hosted on ASF infra are  
actually an issue right now that needs to be resolved at some point  
(ie confluence, nightly builds, demo site, etc).

-David


On Nov 13, 2008, at 12:13 AM, Bruno Busco wrote:

> Hi Enrique,
> I just bumped this thread up because using OFBiz itself in place of
> Confluence and even Jira has been discussed in the Apache Symposium
> (according to David's notes).
>
> I think that setting a server up and running is something HWM will do
> something about.
> On my end I will more than happy to help this happen and kept running.
>
> -Bruno
>
>
> 2008/11/13 Enrique Ruibal <[hidden email]>
>
>>
>> Hello Bruno,
>>
>> What do you have in mind?, Is there something that can be started  
>> on your
>> end?
>>
>> How Can I help with Testing / Documenting stuff?
>>
>> Regards,
>>
>> Enrique R.
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Idea%3A-OFBiz-self-hosting-tp19235405p20471724.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>
>>

[Jacques Le Roux]

Yes and there one day hopefully we will be able to run some type of Continuous Integration. At ASF most projects use Hudson
http://en.wikipedia.org/wiki/Continuous_Integration
http://martinfowler.com/articles/continuousIntegration.html
http://wiki.apache.org/general/Hudson

Of course before that, as Adam outlined, we would have to have a more reliable set of tests.
Maybe, as David suggested, we could enforce our rules about that (no new features without tests).
I'm afraid this would drastically reduce contributions. Maybe it's better to have less but more robust.

I agree that we need marketing, and I think we need as much tests.

Jacques

From: "David E Jones" <[hidden email]>

>
> Actually as we get OFBiz ready to run for OFBiz we'll have it hosted  
> on ASF infra. The OFBiz resources that are not hosted on ASF infra are  
> actually an issue right now that needs to be resolved at some point  
> (ie confluence, nightly builds, demo site, etc).
>
> -David
>
>
> On Nov 13, 2008, at 12:13 AM, Bruno Busco wrote:
>
>> Hi Enrique,
>> I just bumped this thread up because using OFBiz itself in place of
>> Confluence and even Jira has been discussed in the Apache Symposium
>> (according to David's notes).
>>
>> I think that setting a server up and running is something HWM will do
>> something about.
>> On my end I will more than happy to help this happen and kept running.
>>
>> -Bruno
>>
>>
>> 2008/11/13 Enrique Ruibal <[hidden email]>
>>
>>>
>>> Hello Bruno,
>>>
>>> What do you have in mind?, Is there something that can be started  
>>> on your
>>> end?
>>>
>>> How Can I help with Testing / Documenting stuff?
>>>
>>> Regards,
>>>
>>> Enrique R.
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Idea%3A-OFBiz-self-hosting-tp19235405p20471724.html
>>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>>
>>>
>

[Shi Yusen]

+1 to Hudson.

在 2008-11-13四的 08:14 +0100，Jacques Le Roux写道：

> Yes and there one day hopefully we will be able to run some type of Continuous Integration. At ASF most projects use Hudson
> http://en.wikipedia.org/wiki/Continuous_Integration
> http://martinfowler.com/articles/continuousIntegration.html
> http://wiki.apache.org/general/Hudson
>
> Of course before that, as Adam outlined, we would have to have a more reliable set of tests.
> Maybe, as David suggested, we could enforce our rules about that (no new features without tests).
> I'm afraid this would drastically reduce contributions. Maybe it's better to have less but more robust.
>
> I agree that we need marketing, and I think we need as much tests.
>
> Jacques
>
> From: "David E Jones" <[hidden email]>
> >
> > Actually as we get OFBiz ready to run for OFBiz we'll have it hosted  
> > on ASF infra. The OFBiz resources that are not hosted on ASF infra are  
> > actually an issue right now that needs to be resolved at some point  
> > (ie confluence, nightly builds, demo site, etc).
> >
> > -David
> >
> >
> > On Nov 13, 2008, at 12:13 AM, Bruno Busco wrote:
> >
> >> Hi Enrique,
> >> I just bumped this thread up because using OFBiz itself in place of
> >> Confluence and even Jira has been discussed in the Apache Symposium
> >> (according to David's notes).
> >>
> >> I think that setting a server up and running is something HWM will do
> >> something about.
> >> On my end I will more than happy to help this happen and kept running.
> >>
> >> -Bruno
> >>
> >>
> >> 2008/11/13 Enrique Ruibal <[hidden email]>
> >>
> >>>
> >>> Hello Bruno,
> >>>
> >>> What do you have in mind?, Is there something that can be started  
> >>> on your
> >>> end?
> >>>
> >>> How Can I help with Testing / Documenting stuff?
> >>>
> >>> Regards,
> >>>
> >>> Enrique R.
> >>>
> >>> --
> >>> View this message in context:
> >>> http://www.nabble.com/Idea%3A-OFBiz-self-hosting-tp19235405p20471724.html
> >>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
> >>>
> >>>
> >

[Ray-91]

I think it is wrong to suggest you will get less contributions. Once a
test framework and structure is in place writing tests as you go takes
no longer than the development and manual test process, and often it can
reduce the time. I think for more people its a mind set adjustment, but
it means you do more structured testing at the point of development
rather than come back days/weeks/months later to find that obscure bug.

There is a transition period that will be a little bumpy as people
adjust but and as you say sensible decisions need to be made about what
contributions require a test module like new features, bug fixes,
enhancements etc.

Ray


Jacques Le Roux wrote:

> Yes and there one day hopefully we will be able to run some type of
> Continuous Integration. At ASF most projects use Hudson
> http://en.wikipedia.org/wiki/Continuous_Integration
> http://martinfowler.com/articles/continuousIntegration.html
> http://wiki.apache.org/general/Hudson
>
> Of course before that, as Adam outlined, we would have to have a more
> reliable set of tests.
> Maybe, as David suggested, we could enforce our rules about that (no new
> features without tests).
> I'm afraid this would drastically reduce contributions. Maybe it's
> better to have less but more robust.
>
> I agree that we need marketing, and I think we need as much tests.
>
> Jacques

[Pierre Smits]

Before transtioning to Hudson please provide a migration plan, so that
people can plan when and how-to submit contributions.

Regards,

Pierre

On Thu, Nov 13, 2008 at 10:59 AM, Ray <[hidden email]> wrote:

> I think it is wrong to suggest you will get less contributions. Once a
> test framework and structure is in place writing tests as you go takes
> no longer than the development and manual test process, and often it can
> reduce the time. I think for more people its a mind set adjustment, but
> it means you do more structured testing at the point of development
> rather than come back days/weeks/months later to find that obscure bug.
>
> There is a transition period that will be a little bumpy as people
> adjust but and as you say sensible decisions need to be made about what
> contributions require a test module like new features, bug fixes,
> enhancements etc.
>
> Ray
>
>
> Jacques Le Roux wrote:
> > Yes and there one day hopefully we will be able to run some type of
> > Continuous Integration. At ASF most projects use Hudson
> > http://en.wikipedia.org/wiki/Continuous_Integration
> > http://martinfowler.com/articles/continuousIntegration.html
> > http://wiki.apache.org/general/Hudson
> >
> > Of course before that, as Adam outlined, we would have to have a more
> > reliable set of tests.
> > Maybe, as David suggested, we could enforce our rules about that (no new
> > features without tests).
> > I'm afraid this would drastically reduce contributions. Maybe it's
> > better to have less but more robust.
> >
> > I agree that we need marketing, and I think we need as much tests.
> >
> > Jacques
>
>

[Jacques Le Roux]

From: "Ray" <[hidden email]>
>I think it is wrong to suggest you will get less contributions. Once a
> test framework and structure is in place writing tests as you go takes
> no longer than the development and manual test process, and often it can
> reduce the time. I think for more people its a mind set adjustment, but
> it means you do more structured testing at the point of development
> rather than come back days/weeks/months later to find that obscure bug.

I was playing devil's advocate to have more comments, got one elaborated so far, thanks Ray ! :o)

> There is a transition period that will be a little bumpy as people
> adjust but and as you say sensible decisions need to be made about what
> contributions require a test module like new features, bug fixes,
> enhancements etc.

New features is obvious, depending on the shift, enhancements may require, I think bug fixes should not. But I'm newbie in
Continuous Integration so I may be wrong.

Jacques

> Ray
>
>
> Jacques Le Roux wrote:
>> Yes and there one day hopefully we will be able to run some type of
>> Continuous Integration. At ASF most projects use Hudson
>> http://en.wikipedia.org/wiki/Continuous_Integration
>> http://martinfowler.com/articles/continuousIntegration.html
>> http://wiki.apache.org/general/Hudson
>>
>> Of course before that, as Adam outlined, we would have to have a more
>> reliable set of tests.
>> Maybe, as David suggested, we could enforce our rules about that (no new
>> features without tests).
>> I'm afraid this would drastically reduce contributions. Maybe it's
>> better to have less but more robust.
>>
>> I agree that we need marketing, and I think we need as much tests.
>>
>> Jacques
>

[Jacques Le Roux]

This is only a suggestion so far, don't worry as this stage. But yes we should provide what is needed if we go this way.

Thanks

Jacques

From: "Pierre Smits" <[hidden email]>

> Before transtioning to Hudson please provide a migration plan, so that
> people can plan when and how-to submit contributions.
>
> Regards,
>
> Pierre
>
> On Thu, Nov 13, 2008 at 10:59 AM, Ray <[hidden email]> wrote:
>
>> I think it is wrong to suggest you will get less contributions. Once a
>> test framework and structure is in place writing tests as you go takes
>> no longer than the development and manual test process, and often it can
>> reduce the time. I think for more people its a mind set adjustment, but
>> it means you do more structured testing at the point of development
>> rather than come back days/weeks/months later to find that obscure bug.
>>
>> There is a transition period that will be a little bumpy as people
>> adjust but and as you say sensible decisions need to be made about what
>> contributions require a test module like new features, bug fixes,
>> enhancements etc.
>>
>> Ray
>>
>>
>> Jacques Le Roux wrote:
>> > Yes and there one day hopefully we will be able to run some type of
>> > Continuous Integration. At ASF most projects use Hudson
>> > http://en.wikipedia.org/wiki/Continuous_Integration
>> > http://martinfowler.com/articles/continuousIntegration.html
>> > http://wiki.apache.org/general/Hudson
>> >
>> > Of course before that, as Adam outlined, we would have to have a more
>> > reliable set of tests.
>> > Maybe, as David suggested, we could enforce our rules about that (no new
>> > features without tests).
>> > I'm afraid this would drastically reduce contributions. Maybe it's
>> > better to have less but more robust.
>> >
>> > I agree that we need marketing, and I think we need as much tests.
>> >
>> > Jacques
>>
>>
>

[Ray-91]

Bug fixes usually follow the method of, if a test already exists then
you extend the test to show the bug and then you fix the bug. So from a
 regression point of view you should never get hit by that bug again.

The grey area is definitely around bug fixes for code that does not have
a test. In an ideal world you would say "add a test module", but to
start with it might be to much work when the important aspect is to get
the bug fixed. But again you can develop test modules to help track down
and find a bug, if it turns out you developed more test modules than you
needed to fix the bug then the benefit is still there for the project.

Just as a reminder this does all require a test
tool/framework/environment that is easy to develop, execute and get
results from quickly, otherwise it'll be painful and won't get much support.

Ray


Jacques Le Roux wrote:

> From: "Ray" <[hidden email]>
>> I think it is wrong to suggest you will get less contributions. Once a
>> test framework and structure is in place writing tests as you go takes
>> no longer than the development and manual test process, and often it can
>> reduce the time. I think for more people its a mind set adjustment, but
>> it means you do more structured testing at the point of development
>> rather than come back days/weeks/months later to find that obscure bug.
>
> I was playing devil's advocate to have more comments, got one elaborated
> so far, thanks Ray ! :o)
>
>> There is a transition period that will be a little bumpy as people
>> adjust but and as you say sensible decisions need to be made about what
>> contributions require a test module like new features, bug fixes,
>> enhancements etc.
>
> New features is obvious, depending on the shift, enhancements may
> require, I think bug fixes should not. But I'm newbie in Continuous
> Integration so I may be wrong.
>
> Jacques
>
>
>> Ray
>>
>>
>> Jacques Le Roux wrote:
>>> Yes and there one day hopefully we will be able to run some type of
>>> Continuous Integration. At ASF most projects use Hudson
>>> http://en.wikipedia.org/wiki/Continuous_Integration
>>> http://martinfowler.com/articles/continuousIntegration.html
>>> http://wiki.apache.org/general/Hudson
>>>
>>> Of course before that, as Adam outlined, we would have to have a more
>>> reliable set of tests.
>>> Maybe, as David suggested, we could enforce our rules about that (no new
>>> features without tests).
>>> I'm afraid this would drastically reduce contributions. Maybe it's
>>> better to have less but more robust.
>>>
>>> I agree that we need marketing, and I think we need as much tests.
>>>
>>> Jacques
>>
>
>

[David E Jones-3]

On Nov 13, 2008, at 1:14 AM, Jacques Le Roux wrote:

> Maybe, as David suggested, we could enforce our rules about that (no  
> new features without tests).
> I'm afraid this would drastically reduce contributions. Maybe it's  
> better to have less but more robust.

I don't believe I've ever been in favor of enforcing a rule requiring  
new features to be accompanied by automated tests. In fact, I think  
I've spoken/written against that a number of times.

Like you say, this may reduce contributions. The bigger issue with a  
community-driven project is that people are motivated by a small  
number of things:

1. what they or their clients need (strong)
2. social pressure from others in the community (semi-strong)
3. desire for recognition (fairly weak)
4. desire to create something good/new (fairly weak)

A quick note on the strength of these motivations: I'm not trying to  
comment on human nature for all things that a person might do, or that  
would apply to all people, but I am saying that for business-oriented  
software developed in a community-driven model these seemed to be what  
drive actual quantities of hours and actual refinement of what is  
developed.

So, how do we get people to contribute tests? IMO it has nothing to do  
with new functionality, it has everything to do with how people want  
OFBiz to work for them. In short the idea is that if someone wants  
something to keep working a certain way they should contribute an  
automated test for it. It's really that simple, and goes to motivation  
#1.

To make it a stronger motivation, we can use motivation #2 as well.  
When people say "hey this doesn't work any more", or "it is important  
that this always work this way" the response in the mailing lists can  
always be "great, submit an automated test!".

This allows people to invest in what they care about. Of course, to  
make this happen for real and not just seem like a good idea we need  
the testing tools to be as easy and consistent as possible. It needs  
to be easy to create tests, and it needs to be easy to run existing  
tests and to review what existing tests are and do. Those aren't easy  
features to implement. Because of these we've discussed using Selenium  
because it is easy to record test sequenced that test everything from  
the client side UI code to the database in and out. However, running  
these tests and creating suite of them that can run in an automated  
way that is organized by component still needs to be done. Even more  
difficult, it seems right now, is that Selenium depends on some GPL/
LGPL libraries, so we can't include them all in OFBiz, which means  
that either the Selenium licensing is invalid (in the case of GPL  
libraries Selenium would have to also be GPL licensed) or at least it  
is much more difficult to run the tests because we can't include them  
in OFBiz.

-David

[Ean Schuessler]

----- "David E Jones" <[hidden email]> wrote:

> I don't believe I've ever been in favor of enforcing a rule requiring
> new features to be accompanied by automated tests. In fact, I think  
> I've spoken/written against that a number of times.
> Like you say, this may reduce contributions. The bigger issue with a
>
> community-driven project is that people are motivated by a small  
> number of things:
>
> 1. what they or their clients need (strong)
> 2. social pressure from others in the community (semi-strong)
> 3. desire for recognition (fairly weak)
> 4. desire to create something good/new (fairly weak)

I don't think we should underestimate the fact that developing good tests is as distinct a skill set as writing good database code or understanding concurrent programming. One very tough problem about required tests would be that many people simply don't have experience with Selenium or any of the other test frameworks. This is probably especially true as you get into more rarified skill sets. Certainly there will be a few unusual people who feel they can master everything but many people tend to specialize.

Maybe we could have testing play a more central and public role in the project? Try and turn testing into an area that gets you instant recognition? Also, maybe we can look for users that have more of an interest in testing (ie. customers) and get them more involved in core platform testing?

--
Ean Schuessler, CTO Brainfood.com
[hidden email] - http://www.brainfood.com - 214-720-0700 x 315

[Adam Heath-2]

David E Jones wrote:

> [snip stuff about tests]

On that note, it has become my primary non-paid-work concern, to make
the automated tests work out of the box.

One idea that has been mentioned, is running each test in a transaction,
then rolling it back at the end.  This won't work, for several reasons.
 One, is that tests themselves may do multiple transaction things, even
going so far as calling services that spawn separate transactions.  Two,
if the test calls commit, it actually won't, as it's running inside
another transaction started by the test container.

Another idea that has been mentioned, is using the EntityAuditLog
feature.  Since that only deals with single fields, it would need to be
extended.

One I had this morning, is to use Entity Data xml.  Whenever the new
entity is stored, save the old entity into a per-transaction based list.
 When the transaction status changes, either throw it away, or commit
it.  This would  need to be extended to support deletes.

And probably the simplest of all, is to save a copy of
runtime/data/derby, then after each test, shutdown stuff, and copy the
files back in.  Preliminary testing shows that tarring up that dir, not
compressing, then deleting and untarring is the fastest.

[David E Jones-3]

On Nov 13, 2008, at 11:51 AM, Ean Schuessler wrote:

> ----- "David E Jones" <[hidden email]> wrote:
>
>> I don't believe I've ever been in favor of enforcing a rule requiring
>> new features to be accompanied by automated tests. In fact, I think
>> I've spoken/written against that a number of times.
>> Like you say, this may reduce contributions. The bigger issue with a
>>
>> community-driven project is that people are motivated by a small
>> number of things:
>>
>> 1. what they or their clients need (strong)
>> 2. social pressure from others in the community (semi-strong)
>> 3. desire for recognition (fairly weak)
>> 4. desire to create something good/new (fairly weak)
>
> I don't think we should underestimate the fact that developing good  
> tests is as distinct a skill set as writing good database code or  
> understanding concurrent programming. One very tough problem about  
> required tests would be that many people simply don't have  
> experience with Selenium or any of the other test frameworks. This  
> is probably especially true as you get into more rarified skill  
> sets. Certainly there will be a few unusual people who feel they can  
> master everything but many people tend to specialize.

Thanks Ean, that's a very good point.

> Maybe we could have testing play a more central and public role in  
> the project? Try and turn testing into an area that gets you instant  
> recognition? Also, maybe we can look for users that have more of an  
> interest in testing (ie. customers) and get them more involved in  
> core platform testing?

I'm imagining tests coming from 3 main sources:

1. people who want OFBiz to work a certain way, because that is what  
they or their clients need (or want)

2. people who are just interested in QA and testing and would rather  
work on that

3. those who get involved with an effort to define some requirements  
and designs for OFBiz, and create automated tests according to those  
(I've just started working on this, there's a new space on  
docs.ofbiz.org where I'm putting stuff and I'll be writing some intro  
emails about it hopefully soon, it's basically what I'm working on  
today)

Especially as we get more tools in place I hope to see more pressure  
on the mailing list where people are answering questions and comments  
with "great, write an automated test!". I think this is along the same  
lines you're thinking of. Actually, it could start right now. We have  
great tools for writing service level tests, and in fact if someone  
was bored they could even work on resolving some of the data  
dependency problems that exist in those tests now.

Anyway, I agree. Tests need to be a more day-to-day part of the  
project with recognition for having done them, and social pressure to  
do them as well.

At the conference there were a bunch of people who are doing lots of  
stuff based on OFBiz but have only contributed on a limited basis, or  
not really at all. I was wondering if they might be interested in  
participating in this way (ie for testing) and might actually be more  
interested in that than in other types of contributions.

-David

[Scott Gray]

Hi Adam,

I'm no transaction expert but how sure are we that starting a new
transaction just before each test and rolling it back at the end won't
work?  From what I can gather Derby does actually alter the database
prior to committing the transaction but it also creates log records
that allow the changes to undone in case of a rollback.

I just tried it using the JUnitListener class to start and end a
transaction and I can't see any obvious negative effects (aside from
tests failing that relied on data created in previous tests).

Regards
Scott

2008/11/14 Adam Heath <[hidden email]>:

> David E Jones wrote:
>
>> [snip stuff about tests]
>
> On that note, it has become my primary non-paid-work concern, to make
> the automated tests work out of the box.
>
> One idea that has been mentioned, is running each test in a transaction,
> then rolling it back at the end.  This won't work, for several reasons.
>  One, is that tests themselves may do multiple transaction things, even
> going so far as calling services that spawn separate transactions.  Two,
> if the test calls commit, it actually won't, as it's running inside
> another transaction started by the test container.
>
> Another idea that has been mentioned, is using the EntityAuditLog
> feature.  Since that only deals with single fields, it would need to be
> extended.
>
> One I had this morning, is to use Entity Data xml.  Whenever the new
> entity is stored, save the old entity into a per-transaction based list.
>  When the transaction status changes, either throw it away, or commit
> it.  This would  need to be extended to support deletes.
>
> And probably the simplest of all, is to save a copy of
> runtime/data/derby, then after each test, shutdown stuff, and copy the
> files back in.  Preliminary testing shows that tarring up that dir, not
> compressing, then deleting and untarring is the fastest.
>

[Adam Heath-2]

Scott Gray wrote:

> Hi Adam,
>
> I'm no transaction expert but how sure are we that starting a new
> transaction just before each test and rolling it back at the end won't
> work?  From what I can gather Derby does actually alter the database
> prior to committing the transaction but it also creates log records
> that allow the changes to undone in case of a rollback.
>
> I just tried it using the JUnitListener class to start and end a
> transaction and I can't see any obvious negative effects (aside from
> tests failing that relied on data created in previous tests).

The reason that won't work, is that some services are configured to run
in a *separate* transaction, completely separate from the one that is in
the current thread.  In those cases, the current transaction is
suspended, then resumed.

To do the transaction rollback stuff in those cases, becomes rather more
complex.  It's just simpler to save the disk files, and revert them all,
between tests.  Just need to make certain any background threads are
restarted/shutdown.