[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1347) Make SeamTest not dependent on TestNG

Fri May 25 15:42:08 EDT 2007

    [ http://jira.jboss.com/jira/browse/JBSEAM-1347?page=comments#action_12363238 ] 

Michael Youngstrom commented on JBSEAM-1347:
--------------------------------------------

Ok, here is the final word.  Not extending BaseSeamTest.FacesRequest in SeamTest creates a byte code compatibility problem with old tests.  It will cause a compilation error if the test writer attempted to directly imported 'org.jboss.seam.mock.SeamTest.FacesRequest' unnecessarily in their test.  (like the hibernate example LoginTest does)

In the interest of full 100% compatibility I've left the extended BaseSeamTest.FacesRequest in SeamTest.  If we want SeamTest cleaner we can remove the extended inner classes and force people to recompile and remove the optional imports in their tests with 1.3.

> Make SeamTest not dependent on TestNG
> -------------------------------------
>
>                 Key: JBSEAM-1347
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-1347
>             Project: JBoss Seam
>          Issue Type: Feature Request
>    Affects Versions: 1.2.1.GA
>            Reporter: Michael Youngstrom
>         Assigned To: Michael Youngstrom
>             Fix For: 1.3.0.ALPHA
>
>
> It would be nice if it were possible to use SeamTest in a testing framework other than TestNG.  I'm not proposing Seam provide support for any other testing frameworks I just think it would be nice if developers could have the option create their own way of using the meat of SeamTest in their own way without having to depend upon TestNG.
> It would be trivial to move what is currently in SeamTest into an Abstract class (AbstractSeamTest) class and then change SeamTest to extend AbstractSeamTest and specify the testng annotations in that class.  That way people who wish to try and make AbstractSeamTest work in another testing framework they can without still having to depend upon TestNG.
> 100% backwards compatibility, No documentation changes, just a simple refactor.
> I believe this issue has low risk and I would be more than happy to take on this issue if approved.  I would also like this issue to be considered for inclusion in 1.3.0.
> If you want a patch before approving it I can provide that too.
> Mike

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira