4:12 a.m.
Hi John, thanks for posting this here so that everybody can see and
comment. More inline...
On 01/23/2015 07:41 PM, John Sanda wrote:
The decision was made a while ago to migrate from TestNG to JUnit.
There
was a PR[1] that migrated some of the integration tests to JUnit. I
wound up rejecting the PR and keeping the integration tests in TestNG
because it is not clear to me how JUnit supports some of the features
that we have used and will continue to use with TestNG. Dependent
methods is a good example.
This seems to imply that we use Dependent methods in rhq-metrics
already. Sorry, I am not aware of that. Could you please point me to
tests using them?
For the metrics aggregation tests in RHQ,
Or you mean the old RHQ project here?
there are tests for computing the 1 hr metrics, and there are tests
for
computing the 6 hr metrics. The 6 hr metrics test depends on the 1 hr
metrics test.
[Assuming that the following is a required feature distinct from
dependent tests]
In JUnit the set up/tear down methods are considered part
of the test fixture. In TestNG, they are configuration methods. This is
a big difference because if a configuration method fails, then
subsequent tests are skipped. This makes a lot of sense for integration
tests. If I cannot create a connection to the database for example, then
it is pointless to run the tests which rely on that connection.
"The JUnit way is to do this at runtime is org.junit.Assume."
http://stackoverflow.com/a/1689309 This is exactly what we need, is it not?
My understanding is that there were a couple reasons for the change -
1)
Arquillian has better support for JUnit than for TestNG and 2) JUnit is
more up to date than earlier versions like 3.x (e.g., annotation
driven). hawkular-metrics does not use Arquillian so I do not care about
1) and 2) is not much of a reason. Unless JUnit provides similar
capabilities, I prefer to keep integration/functional tests in TestNG
for hawkular-metrics.
So you propose to remove jUnit from metrics altogether, right?
There is also reason 3) for introducing metrics: more mainstream, no
need to learn new testing framework for more devs, having more tests and
better coverage as a result.
Unless JUnit provides similar capabilities
Yes, we should state clearly, what is required but missing in jUnit. Now
it seems that only dependent tests could fall into this category (but I
am still not convinced that we really need them). Can anybody name other
important features missing from jUnit?
Thanks,
Peter
[1] https://github.com/rhq-project/rhq-metrics/pull/101
- John
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev