That's because it is real applications, so you can import it in JBoos Tools compile, deploy and run.

Max Rydahl Andersen wrote: > Hi guys, > > Why are we adding *tons* of duplicated jars and complete JSF/Seam projects just to unittests a few pages with templates?! > > I can't beleive all of those files are really necessary to check if a myfaces template page will render correctly. > > Could we please make sure our tests just include what is needed and not add tons of unused things. Thanks! > > /max > >

-----Original Message----- From: Max Rydahl Andersen [mailto:max.andersen@redhat.com] Sent: Tuesday, January 22, 2008 8:02 PM To: Max Rydahl Andersen; Denis Golovin Cc: jbosstools-dev(a)lists.jboss.org; external-exadel-list(a)redhat.com; ruby(a)exadel.com Subject: Re: waaay to many jars in junittests What is the status of this ? I just saw Victor commit yet another full seam 2 application to test *one specific issue* in JSF code completion. It cannot be true we need 80(!) files in each of our unittests. /max >> That's because it is real applications, so you can import it in JBoos >> Tools compile, deploy and run. > > What usage does that have ? > > The unit tests for testing 3-4 methods in an API have no reason for messing around with huge projects. > > e.g. I just committed a full junit test for testing the HQL query validation; that only requires 1 entity java class, 1 ejb3-persistence.jar to get the annotations to compile - done. Much easier to maintain/extend and the unit test is much more focused - meaning less wheels to turn to make things work. > > Testing if a .xhtml page is rendered correctly does *not* require that the application is deployable...heck it does not even require any jars as far as i'm concerned. It just requires a .xhtml page and that you can open the file in the editor - maybe the project needs to get JSF enabled to test some of the interactions when that is enabled; but you definitly need to check both scenarioes then (our jsf editor should be usable without the current project being fully configured) > > Note: having test that does the whole thing is relevant, but having a full app for each small test of important functionallity is a big overhead. > > /max > >> Max Rydahl Andersen wrote: >>> Hi guys, >>> >>> Why are we adding *tons* of duplicated jars and complete JSF/Seam projects just to unittests a few pages with templates?! >>> >>> I can't beleive all of those files are really necessary to check if a myfaces template page will render correctly. >>> >>> Could we please make sure our tests just include what is needed and not add tons of unused things. Thanks! >>> >>> /max >>> >>> >> >> > > > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Test project is cut up to 3 files. Studio have all the taglibs needed to support this kind of CA. Victor

On Tue, 22 Jan 2008 18:22:36 +0100, Victor V. Rubezhny <vrubezhny(a)exadel.com&gt; wrote: > Max, > > It seems you right. And we don't need a full seam application to test the > issue. yes. > I will try to reproduce it using jsf only. we don't even need a full jsf project...just the .xhtml file or is more jsf enablement needed ? /max > Victor > >> -----Original Message----- >> From: Max Rydahl Andersen [mailto:max.andersen@redhat.com] >> Sent: Tuesday, January 22, 2008 8:02 PM >> To: Max Rydahl Andersen; Denis Golovin >> Cc: jbosstools-dev(a)lists.jboss.org; >> external-exadel-list(a)redhat.com; ruby(a)exadel.com >> Subject: Re: waaay to many jars in junittests >> >> >> What is the status of this ? >> >> I just saw Victor commit yet another full seam 2 application to >> test *one specific issue* in JSF code completion. >> It cannot be true we need 80(!) files in each of our unittests. >> >> /max >> >> >> That's because it is real applications, so you can import it in JBoos >> >> Tools compile, deploy and run. >> > >> > What usage does that have ? >> > >> > The unit tests for testing 3-4 methods in an API have no reason >> for messing around with huge projects. >> > >> > e.g. I just committed a full junit test for testing the HQL >> query validation; that only requires 1 entity java class, 1 >> ejb3-persistence.jar to get the annotations to compile - done. >> Much easier to maintain/extend and the unit test is much more >> focused - meaning less wheels to turn to make things work. >> > >> > Testing if a .xhtml page is rendered correctly does *not* >> require that the application is deployable...heck it does not >> even require any jars as far as i'm concerned. It just requires >> a .xhtml page and that you can open the file in the editor - >> maybe the project needs to get JSF enabled to test some of the >> interactions when that is enabled; but you definitly need to >> check both scenarioes then (our jsf editor should be usable >> without the current project being fully configured) >> > >> > Note: having test that does the whole thing is relevant, but >> having a full app for each small test of important functionallity >> is a big overhead. >> > >> > /max >> > >> >> Max Rydahl Andersen wrote: >> >>> Hi guys, >> >>> >> >>> Why are we adding *tons* of duplicated jars and complete >> JSF/Seam projects just to unittests a few pages with templates?! >> >>> >> >>> I can't beleive all of those files are really necessary to >> check if a myfaces template page will render correctly. >> >>> >> >>> Could we please make sure our tests just include what is >> needed and not add tons of unused things. Thanks! >> >>> >> >>> /max >> >>> >> >>> >> >> >> >> >> > >> > >> > >> >> >> >> -- >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > >

Another example of why our unittests should not have stuff in them that is unrelated to what they are actually testing: Running HtmlAllTest today gives us the following error in all 50 tests: *** ERROR ***: Sun Jan 27 10:23:18 CET 2008 Java Model Exception: Core Exception [code 0] Runtime JBoss 4.2 Runtime does not exist. This classpath container cannot be initialized. at org.eclipse.jdt.internal.core.JavaModelManager.initializeContainer(JavaModelManager.java:2242) at org.eclipse.jdt.internal.core.JavaModelManager.getClasspathContainer(JavaModelManager.java:1546) at org.eclipse.jdt.core.JavaCore.getClasspathContainer(JavaCore.java:1571) at org.eclipse.jdt.internal.core.JavaProject.resolveClasspath(JavaProject.java:2558) at org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1873) at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathContainer.update(J2EEComponentClasspathContainer.java:203) at org.eclipse.jst.j2ee.internal.common.classpath.J2EEComponentClasspathContainer.getClasspathEntries(J2EEComponentClasspathContainer.java:316) at org.eclipse.jdt.internal.core.JavaModelManager.containerPutIfInitializingWithSameEntries(JavaModelManager.java:547) at org.eclipse.jdt.internal.core.SetContainerOperation.executeOperation(SetContainerOperation.java:49) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:720) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:780) The error occurs because of a change in how our classpathcontainer for a runtime are handling that the runtime is not there. So what is wrong with this ? Isn't it great we found out that the new classpathcontainer handling is breaking our stuff ? Well no, since the new classpathcontainer is probably correct and if the unittests were actually dependent on having a JBoss runtime why aren't they creating one ? Why are the test for the visual editor html templates failing because some totally unrelated server runtime is not there ? This should not happen. It is only happening because the used test project was blindly added with no consideration over what is the actual things we want to test and what is the exact minimal requirements for the function to work! The same issue actually exists for the usage of the JRE_CONTAINER: <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jdk1.5.0_13"/> Who says that the installed jdk would be jdk1.5.0_13 ? Please remember that when updating and writing tests. Thanks! p.s. the new classpathcontainer needs unittests too but that is another issue. /max >>Test project is cut up to 3 files. >>Studio have all the taglibs needed to support this kind of CA. >>Victor > > Great, that's what i'm talking about! Thanks Victor! > > /max > >> On Tue, 22 Jan 2008 18:22:36 +0100, Victor V. Rubezhny <vrubezhny(a)exadel.com&gt; wrote: >> >>> Max, >>> >>> It seems you right. And we don't need a full seam application to test the >>> issue. >> >> yes. >> >>> I will try to reproduce it using jsf only. >> >> we don't even need a full jsf project...just the .xhtml file or is more jsf enablement needed ? >> >> /max >> >>> Victor >>> >>>> -----Original Message----- >>>> From: Max Rydahl Andersen [mailto:max.andersen@redhat.com] >>>> Sent: Tuesday, January 22, 2008 8:02 PM >>>> To: Max Rydahl Andersen; Denis Golovin >>>> Cc: jbosstools-dev(a)lists.jboss.org; >>>> external-exadel-list(a)redhat.com; ruby(a)exadel.com >>>> Subject: Re: waaay to many jars in junittests >>>> >>>> >>>> What is the status of this ? >>>> >>>> I just saw Victor commit yet another full seam 2 application to >>>> test *one specific issue* in JSF code completion. >>>> It cannot be true we need 80(!) files in each of our unittests. >>>> >>>> /max >>>> >>>> >> That's because it is real applications, so you can import it in JBoos >>>> >> Tools compile, deploy and run. >>>> > >>>> > What usage does that have ? >>>> > >>>> > The unit tests for testing 3-4 methods in an API have no reason >>>> for messing around with huge projects. >>>> > >>>> > e.g. I just committed a full junit test for testing the HQL >>>> query validation; that only requires 1 entity java class, 1 >>>> ejb3-persistence.jar to get the annotations to compile - done. >>>> Much easier to maintain/extend and the unit test is much more >>>> focused - meaning less wheels to turn to make things work. >>>> > >>>> > Testing if a .xhtml page is rendered correctly does *not* >>>> require that the application is deployable...heck it does not >>>> even require any jars as far as i'm concerned. It just requires >>>> a .xhtml page and that you can open the file in the editor - >>>> maybe the project needs to get JSF enabled to test some of the >>>> interactions when that is enabled; but you definitly need to >>>> check both scenarioes then (our jsf editor should be usable >>>> without the current project being fully configured) >>>> > >>>> > Note: having test that does the whole thing is relevant, but >>>> having a full app for each small test of important functionallity >>>> is a big overhead. >>>> > >>>> > /max >>>> > >>>> >> Max Rydahl Andersen wrote: >>>> >>> Hi guys, >>>> >>> >>>> >>> Why are we adding *tons* of duplicated jars and complete >>>> JSF/Seam projects just to unittests a few pages with templates?! >>>> >>> >>>> >>> I can't beleive all of those files are really necessary to >>>> check if a myfaces template page will render correctly. >>>> >>> >>>> >>> Could we please make sure our tests just include what is >>>> needed and not add tons of unused things. Thanks! >>>> >>> >>>> >>> /max >>>> >>> >>>> >>> >>>> >> >>>> >> >>>> > >>>> > >>>> > >>>> >>>> >>>> >>>> -- >>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >>> >>> >> >> >> > > >

Max (and all): I'm running into this issue too now that I'm reworking some of the unit tests on classpath containers. The question I have is how best to configure my example project? Right now it seems to grab from a hard-coded JRE container.

I guess my question is, can we all look into standardizing a JRE name / classpath container path that we can all use and expect to run properly in all of our unit tests? I feel that since this is a common problem we should all know what our standard is. I'm sure I could analyze it myself and figure out what will work for me, but I'd prefer if we had some standard. - Rob Max Rydahl Andersen wrote: > The same issue actually exists for the usage of the JRE_CONTAINER: > <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jdk1.5.0_13"/> > > Who says that the installed jdk would be jdk1.5.0_13 ? > > Please remember that when updating and writing tests. > > Thanks!