Interesting. Let me forward it to my team and see what we come up with. I'll report back soon.
On Tue, Nov 6, 2012 at 2:12 PM, Mauro Talevi <mauro.tal...@aquilonia.org>wrote: > I understand the goals and I can see why you'd want this feature. I'd > like to find a solution that does not involve code duplication. > > Ideally, I'd like to have a generics-enabled RunnableStories<T> class that > we can use for both JUnit and TestNG. > > Maybe playing with proxies (e.g. proxytoys)? Perhaps we could provide a > generated class (generated by a Ant/Maven goal) that can be extended. > > What do you think? > > Cheers > > > On 06/11/2012 03:22, Justin Holmes wrote: > > Goals driving this feature request: > 1) Client code doesn't need to bring in the JUnit dependency if it plans > to use TestNG > 2) Client code doesn't need to manage its own TestNGStories (As in the > trader example) or override the run method each time > > Sounds like TestNGStory/TestNGStories are more trouble than they are > worth for the framework, so I'll continue to meet these goals on the > client-side. > > Thanks for your time and attention. > > > On Fri, Nov 2, 2012 at 6:24 PM, Mauro Talevi > <mauro.tal...@aquilonia.org>wrote: > >> Yes, your point is understood. But apart from the name, what is your >> concern about using JUnitStory directly with the JUnit annotation? >> >> My concern is the unnecessary duplication of code and support of another >> dependency for no appreciable gain. >> >> We're using the @Test annotation for the bare minimum boostrap a single >> execution of stories, not unit tests. So the features that would normally >> bring you to prefer TestNG over JUnit for unit testing don't apply here. >> >> What would using TestNG provide that JUnit does not in running JBehave >> stories? >> >> >> On Fri Nov 2 19:04:59 2012, Justin Holmes wrote: >> >>> Are you referring to >>> >>> https://github.com/jbehave/jbehave-core/blob/master/examples/trader-testng/src/main/java/org/jbehave/examples/trader/testng/TestNGTraderStories.java >>> ? >>> If you dig down the class hierarchy, it inherits from JUnitStories and >>> then overrides the run method. Although it is simply a matter of >>> switching an import statement, I think it would be nice to say that >>> JBehave also support TestNG "out-of-the-box" via a TestNGStory and >>> TestNGStories. >>> >>> If there are no concerns, I would be happy to submit a pull request >>> myself. >>> >>> >>> >>> >>> On Fri, Nov 2, 2012 at 2:35 PM, Mauro Talevi >>> <mauro.tal...@aquilonia.org <mailto:mauro.tal...@aquilonia.org>> wrote: >>> >>> That's correct. It's really nothing to do with JUnit nor with >>> unit testing. It's simply a hook to bootstrap the execution of >>> the stories. >>> >>> We could try to make it more generic in 4.x, but I'm not entirely >>> sure it's top priority. >>> >>> >>> On 02/11/2012 18:09, Alexander Lehmann wrote: >>> >>> there is a testng example in the examples directory in the >>> jbehave-core source, this essentially uses a testng @Test >>> annotation for the run method, inheriting from the Stories >>> class, however I assume it doesn't call any of the junit methods. >>> >>> On 01.11.2012 21:36, Justin Holmes wrote: >>> >>> Hello Devs, >>> >>> I'm on a project that uses TestNG as its Unit test >>> framework so I'd like >>> to leverage it for JBehave. I've seen ways to do that (e.g. >>> http://jbehave.org/reference/__preview/faq.html >>> >>> <http://jbehave.org/reference/preview/faq.html> ) but its >>> just seems >>> unnatural to extend a class "JUnitStories" if I'm not >>> using JUnit. I've >>> searched through the jira and the mail list, but can't >>> find a specific >>> reference to this question. Is there a particular reason that >>> TestNGStory/Stories does not exists in jbehave-core? Maybe >>> dependency >>> issues? If there is not, I'd be happy to submit a pull >>> request and add >>> the feature. >>> >>> >>> - Justin >>> >>> >>> >>> >>> >>> ------------------------------__------------------------------__--------- >>> >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/__manage_email >>> <http://xircles.codehaus.org/manage_email> >>> >>> >>> >>> >>> >>> ------------------------------__------------------------------__--------- >>> >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/__manage_email >>> <http://xircles.codehaus.org/manage_email> >>> >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > >
