Please read & review: "Test your module" - seam-dev - Jboss List Archives

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Please read & review: "Test your module"

Version Label Consistency

Build status emails

Lincoln Baxter, III

Monday, 26 April 2010 Mon, 26 Apr '10

1:57 p.m.

http://seamframework.org/Seam3/ModuleHandbook http://seamframework.org/Seam3/ModuleTesting This includes a few guidelines, plus step-by-step instructions for getting started writing JUnit and Arquillian tests. Please review and add/comment. Thanks, -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

Attachments:

attachment.html (text/html — 582 bytes)

Reply

Show replies by thread

Dan Allen

Monday, 26 April Mon, 26 Apr

3:08 p.m.

Good job. This is an excellent step forward. I made a few copy edits. I also added a little bit more detail around the recommendation to use JUnit. We've traditionally used TestNG for Seam, but because the IDE support for TestNG is so flaky in Eclipse and JUnit integrates much cleaner with Arquilian, I'm in support of the change. We need some fixes to JUnit, like categories, but the Arquillian team can pursue those. Please let them know your needs! [1] Speaking of needs, please add a recommendation to use the Arquillian discussion forums when you need guidance with Arquillian. There is one gap in the article at this point. Right now it assumes the use of the weld-embedded container. That will work for basic managed bean tests, but it's not going to work for integration tests that require container services such as JMS and JPA. It also won't be sufficient when we need to test the real JSF life cycle. Therefore, I recommend adding a section about using real containers. For instance, JMS module needs this right out of the gate. -Dan [1] http://community.jboss.org/en/arquillian On Mon, Apr 26, 2010 at 1:57 PM, Lincoln Baxter, III < lincolnbaxter(a)gmail.com> wrote:

http://seamframework.org/Seam3/ModuleHandbook http://seamframework.org/Seam3/ModuleTesting This includes a few guidelines, plus step-by-step instructions for getting started writing JUnit and Arquillian tests. Please review and add/comment. Thanks, -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

-- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

Reply

Nicklas Karlsson

Tuesday, 27 April Tue, 27 Apr

3:57 a.m.

There is one gap in the article at this point. Right now it assumes the use of the weld-embedded container. That will work for basic managed bean tests, but it's not going to work for integration tests that require container services such as JMS and JPA. It also won't be sufficient when we need to test the real JSF life cycle. Therefore, I recommend adding a section about using real containers. For instance, JMS module needs this right out of the gate.

I don't know if it's a job for this article or for Arquillian/JBossTesting in general but it would be handy to show the progression of a simple case from the standalone unit test to the full blown EE-integration test. Something along the lines of * A simple junit-only test of a Calc class that returns the sum of two parameters * Calc in embedded weld with some injection * Calc goes servlet (HTMLUnit? Selenium?) * Calc goes JSF-WAR web app (JSFUnit?) * Calc goes JSF-EAR-JPA (DBUnit + loading of data + transactions etc) --- Nik

Reply

Pete Muir

7:53 a.m.

On 27 Apr 2010, at 08:57, Nicklas Karlsson wrote:

There is one gap in the article at this point. Right now it assumes the use of the weld-embedded container. That will work for basic managed bean tests, but it's not going to work for integration tests that require container services such as JMS and JPA. It also won't be sufficient when we need to test the real JSF life cycle. Therefore, I recommend adding a section about using real containers. For instance, JMS module needs this right out of the gate. I don't know if it's a job for this article or for Arquillian/JBossTesting in general but it would be handy to show the progression of a simple case from the standalone unit test to the full blown EE-integration test. Something along the lines of

Agreed, this would be nice for the Arquillian guide - http://docs.jboss.org/arquillian/reference/1.0.0.Alpha1/en-US/html/exampl... Can you file an ARQ issue?

Reply

Dan Allen

2:18 p.m.

On Tue, Apr 27, 2010 at 3:57 AM, Nicklas Karlsson <nickarls(a)gmail.com>wrote:

There is one gap in the article at this point. Right now it assumes the use > of the weld-embedded container. That will work for basic managed bean tests, > but it's not going to work for integration tests that require container > services such as JMS and JPA. It also won't be sufficient when we need to > test the real JSF life cycle. Therefore, I recommend adding a section about > using real containers. For instance, JMS module needs this right out of the > gate. > I don't know if it's a job for this article or for Arquillian/JBossTesting in general but it would be handy to show the progression of a simple case from the standalone unit test to the full blown EE-integration test. Something along the lines of * A simple junit-only test of a Calc class that returns the sum of two parameters * Calc in embedded weld with some injection * Calc goes servlet (HTMLUnit? Selenium?) * Calc goes JSF-WAR web app (JSFUnit?) * Calc goes JSF-EAR-JPA (DBUnit + loading of data + transactions etc)

That's more or less what I was referring to. While I see this as something for the Arquillian reference guide, I still think it would be useful to have the no frills progression on the ModuleTesting page. The reference documentation can have the show and tell whereas the ModulesTesting page can just have the show. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

Reply

Ken Finnigan

Wednesday, 28 April Wed, 28 Apr

9:44 p.m.

Lincoln, Great first cut on testing for modules. One question, one comment Pete made about some testing code I had committed for the i18n module was that classes for tests should be in a "test" package as opposed to being in the same package as the main source. Are we going with that approach or having test classes in the same package but only under different source tree? Ken On 26/04/2010 18:57, Lincoln Baxter, III wrote:

http://seamframework.org/Seam3/ModuleHandbook http://seamframework.org/Seam3/ModuleTesting This includes a few guidelines, plus step-by-step instructions for getting started writing JUnit and Arquillian tests. Please review and add/comment. Thanks, -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

Reply

Lincoln Baxter, III

Thursday, 29 April Thu, 29 Apr

1 a.m.

Yeah, that's right. Maven ensures that classes under the src/main/test/ folder are never included in the final packaged build. So using a parallel package structure to src/main/java, for example, keeps things nice and separate :) You can take a look at the Faces module for some more examples, but it looks like I18N is right on. --Lincoln On Wed, Apr 28, 2010 at 9:44 PM, Ken Finnigan <ken.finnigan(a)sorstech.com>wrote:

Lincoln, Great first cut on testing for modules. One question, one comment Pete made about some testing code I had committed for the i18n module was that classes for tests should be in a "test" package as opposed to being in the same package as the main source. Are we going with that approach or having test classes in the same package but only under different source tree? Ken On 26/04/2010 18:57, Lincoln Baxter, III wrote: http://seamframework.org/Seam3/ModuleHandbook http://seamframework.org/Seam3/ModuleTesting This includes a few guidelines, plus step-by-step instructions for getting started writing JUnit and Arquillian tests. Please review and add/comment. Thanks, -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

-- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

Reply

Lincoln Baxter, III

1:01 a.m.

PS -- This means use a parallel test package structure :) sorry, missed the point for a second! On Thu, Apr 29, 2010 at 1:00 AM, Lincoln Baxter, III < lincolnbaxter(a)gmail.com> wrote:

Yeah, that's right. Maven ensures that classes under the src/main/test/ folder are never included in the final packaged build. So using a parallel package structure to src/main/java, for example, keeps things nice and separate :) You can take a look at the Faces module for some more examples, but it looks like I18N is right on. --Lincoln On Wed, Apr 28, 2010 at 9:44 PM, Ken Finnigan <ken.finnigan(a)sorstech.com>wrote: > Lincoln, > > Great first cut on testing for modules. > > One question, one comment Pete made about some testing code I had > committed for the i18n module was that classes for tests should be in a > "test" package as opposed to being in the same package as the main source. > Are we going with that approach or having test classes in the same package > but only under different source tree? > > Ken > > > > On 26/04/2010 18:57, Lincoln Baxter, III wrote: > > http://seamframework.org/Seam3/ModuleHandbook > http://seamframework.org/Seam3/ModuleTesting > > This includes a few guidelines, plus step-by-step instructions for getting > started writing JUnit and Arquillian tests. Please review and add/comment. > > Thanks, > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" > > > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

-- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

Reply

Pete Muir

7:13 a.m.

I still have a problem with this. It makes it *very* hard to differentiate quickly between a test class and a impl/api class when quickly scanning a stack trace, or a list of class names. What is the reason for not continuing with the current convention of using org.jboss.seam.blah.tests? Pete On 29 Apr 2010, at 06:01, Lincoln Baxter, III wrote:

PS -- This means use a parallel test package structure :) sorry, missed the point for a second! On Thu, Apr 29, 2010 at 1:00 AM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com> wrote: Yeah, that's right. Maven ensures that classes under the src/main/test/ folder are never included in the final packaged build. So using a parallel package structure to src/main/java, for example, keeps things nice and separate :) You can take a look at the Faces module for some more examples, but it looks like I18N is right on. --Lincoln On Wed, Apr 28, 2010 at 9:44 PM, Ken Finnigan <ken.finnigan(a)sorstech.com> wrote: Lincoln, Great first cut on testing for modules. One question, one comment Pete made about some testing code I had committed for the i18n module was that classes for tests should be in a "test" package as opposed to being in the same package as the main source. Are we going with that approach or having test classes in the same package but only under different source tree? Ken On 26/04/2010 18:57, Lincoln Baxter, III wrote: > http://seamframework.org/Seam3/ModuleHandbook > http://seamframework.org/Seam3/ModuleTesting > > This includes a few guidelines, plus step-by-step instructions for getting started writing JUnit and Arquillian tests. Please review and add/comment. > > Thanks, > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" > > _______________________________________________ > seam-dev mailing list > > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev > > > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

Reply

Lincoln Baxter, III

9:06 a.m.

What is the reason for not continuing with the current convention of using org.jboss.seam.blah.tests?

I didn't know we had that convention ;) Though, that's pretty much the same thing as ClassUnderTest**Test.java(line#), right? Which is something you need to have for SureFire to work anyway. --LB On Thu, Apr 29, 2010 at 7:13 AM, Pete Muir <pmuir(a)redhat.com> wrote:

I still have a problem with this. It makes it *very* hard to differentiate quickly between a test class and a impl/api class when quickly scanning a stack trace, or a list of class names. Pete On 29 Apr 2010, at 06:01, Lincoln Baxter, III wrote: > PS -- This means use a parallel test package structure :) sorry, missed the point for a second! > > On Thu, Apr 29, 2010 at 1:00 AM, Lincoln Baxter, III < lincolnbaxter(a)gmail.com> wrote: > Yeah, that's right. Maven ensures that classes under the src/main/test/ folder are never included in the final packaged build. So using a parallel package structure to src/main/java, for example, keeps things nice and separate :) > > You can take a look at the Faces module for some more examples, but it looks like I18N is right on. > > --Lincoln > > > On Wed, Apr 28, 2010 at 9:44 PM, Ken Finnigan <ken.finnigan(a)sorstech.com> wrote: > Lincoln, > > Great first cut on testing for modules. > > One question, one comment Pete made about some testing code I had committed for the i18n module was that classes for tests should be in a "test" package as opposed to being in the same package as the main source. Are we going with that approach or having test classes in the same package but only under different source tree? > > Ken > > > > On 26/04/2010 18:57, Lincoln Baxter, III wrote: >> http://seamframework.org/Seam3/ModuleHandbook >> http://seamframework.org/Seam3/ModuleTesting >> >> This includes a few guidelines, plus step-by-step instructions for getting started writing JUnit and Arquillian tests. Please review and add/comment. >> >> Thanks, >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.com >> http://scrumshark.com >> "Keep it Simple" >> >> _______________________________________________ >> seam-dev mailing list >> >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> >> > > > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" > > > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" > _______________________________________________ > seam-dev mailing list > seam-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/seam-dev

-- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

Reply

5115

days inactive

5118

days old

seam-dev@lists.jboss.org

Manage subscription

9 comments

5 participants

tags (0)

participants (5)

Dan Allen
Ken Finnigan
Lincoln Baxter, III
Nicklas Karlsson
Pete Muir