Sure. Try an ant task called <junit4> from randomizedtesting package here:

http://labs.carrotsearch.com/randomizedtesting.html

The task is a nearly drop-in replacement for <junit> but forks one or more
JVMs (configurable) and runs tests in parallel. For example (complex)
configuration of running tests in parallel take a look at Apache Lucene
project (in trunk) because it uses <junit4> internally.

Dawid

On Fri, Jun 29, 2012 at 6:13 AM, Aaron V. <gruen0aermel@...> wrote:

> **
>
>
> Are there any open-source libraries out there for launching junit tests
> and reporting back the results (such as might be done by an IDE, similar to
> Eclipse's JDT RemoteTestRunner, but intended to be reused by others) ?
>
> I've found the several projects that have internal components that do
> this, but I'm curious to know if there are any stand-alone libraries that
> provide an API for this sort of functionality.
>
> These are the OSS projects I've found with internal components for forking
> junit--if there are any other notable ones, I'd be happy to hear about them
> as well:
> - Eclipse JDT - RemoteTestRunner, etc
> - maven-surefire-common - booterclient package
> - intellij-community - JUnit4IdeaTestRunner
>
> Thanks!
> --Aaron V.
>
>
>


[Non-text portions of this message have been removed]

[This is a recording.]

I'm out June 24 - July 1, 2012.
I'll be reading mail occasionally.

	 Bill

Aaron V. wrote on 29.6.2012 7:13:
> Are there any open-source libraries out there for launching junit tests
> and reporting back the results (such as might be done by an IDE, similar
> to Eclipse's JDT RemoteTestRunner, but intended to be reused by others) ?
>
> I've found the several projects that have internal components that do
> this, but I'm curious to know if there are any stand-alone libraries
> that provide an API for this sort of functionality.

I'm working on a new test runner (backward compatible with JUnit tests)
which is such a stand-alone library with zero external dependencies:

http://jumi.fi/

The first public release should happen this July, when I have holiday
from work and time to work on it. The events which you get from tests
are those which are now in SuiteListener [1] plus soon also events about
printing to stdout/stderr. Some day later each event will also come with
a timestamp and thread name, and there will be an event which tells all
environment details (system properties, JVM version etc.).

[1]
https://github.com/orfjackal/jumi/blob/6967a4f7e2113cf53f8c799d5ffdf8efecb8bebb/\
jumi-core/src/main/java/fi/jumi/core/SuiteListener.java

--
Esko Luontola
www.orfjackal.net

>
> printing to stdout/stderr. Some day later each event will also come with
> a timestamp and thread name, and there will be an event which tells all
> environment details (system properties, JVM version etc.).
>

Interesting. This was part of the reason for that junit4 task I mentioned
-- I needed a coordinated, full set of events from forked jvms (including
sysouts, threading, etc.). This is already implemented (and pretty heavily
tested) under

https://github.com/carrotsearch/randomizedtesting/

so we may want to join efforts if you want.

Dawid


[Non-text portions of this message have been removed]

The "automatic" unsubscribe doesn' work.

Thanks,

Indrit

On 29/giu/2012, at 10:56, Dawid Weiss <dawid.weiss@...> wrote:

> >
> > printing to stdout/stderr. Some day later each event will also come with
> > a timestamp and thread name, and there will be an event which tells all
> > environment details (system properties, JVM version etc.).
> >
>
> Interesting. This was part of the reason for that junit4 task I mentioned
> -- I needed a coordinated, full set of events from forked jvms (including
> sysouts, threading, etc.). This is already implemented (and pretty heavily
> tested) under
>
> https://github.com/carrotsearch/randomizedtesting/
>
> so we may want to join efforts if you want.
>
> Dawid
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
>

[Non-text portions of this message have been removed]

Dawid Weiss wrote on 29.6.2012 11:56:
> Interesting. This was part of the reason for that junit4 task I mentioned
> -- I needed a coordinated, full set of events from forked jvms (including
> sysouts, threading, etc.). This is already implemented (and pretty heavily
> tested) under
>
> https://github.com/carrotsearch/randomizedtesting/
>
> so we may want to join efforts if you want.

My goals for developing Jumi are wider than that and I don't think that
it would be possible to reuse anything JUnit-specific.

Some of the main reason for creating a new test runner was to better
support testing frameworks which (1) don't know what tests there are
before executing them, (2) contain nested tests. For example specs,
ScalaTest and Specsy (by me, http://specsy.org/) fall into these
categories. The causes of these issues are implicit assumptions in
JUnit's Runner interface and overcoming them requires changing the API.

Other goals relate to usability. For example I think that all current
IDEs and build tools suffer from the issue that the following code in a
test won't print "abc", but will more probably print "acb" or "bac":

    System.out.print("a");
    System.err.print("b");
    System.out.print("c");

Also it's not possible to run with one command all tests of a
multi-module Maven project in IDEA or Eclipse, when different modules
have conflicting classpaths (such as different versions of the same
library) or their tests require module-specific working directories
(which IIRC is the default in Maven Surefire Plugin).

The rest of the goals relate to running tests faster: parallel
execution, test order priorization, class loader caching etc.

--
Esko Luontola
www.orfjackal.net

Ok, clear.


>
> Other goals relate to usability. For example I think that all current
> IDEs and build tools suffer from the issue that the following code in a
> test won't print "abc", but will more probably print "acb" or "bac":
>
> System.out.print("a");
> System.err.print("b");
> System.out.print("c");
>
>
This has nothing to do with test frameworks -- you can see any of these
orderings on the console too and it is allowed by PrintStream contracts
(unless you redirect to a single underlying stream or coordinate all print
events manually which isn't the case by default).

Dawid


[Non-text portions of this message have been removed]

Hi,

I'm trying to implement a test rule that handles unstable tests.

It's made up of the test rule itself, plus an Unstable annotation that you can
put either on the class or on a single method.

The way I wrote it is similar to
http://stackoverflow.com/questions/8295100/how-to-re-run-failed-junit-tests-imme\
diately, in that it just evaluates the statement again.

Normally before a test method is invoked, the test class fields are initialized.
The problem with the retry is that since the same statement is reused, the
fields will not be re-initialized between retries.

I've tried to find a solution to this. It looks to me like I would have to
create my own test runner to achieve this, which ideally I would like to avoid.

Am I correct in that I have to create a custom test runner, or can it be done in
some other way?


Thanks

Daniel

Hi, all.

I'm back from an extended vacation.  I'll be working slowly through github
issues, but haven't been closely monitoring the list.  If there's anything
you'd really like me to chime in on, feel free to ping me.  Thanks!

    David Saff


[Non-text portions of this message have been removed]

Hello experts,

I am working on a project having several Junit 4.10 test cases driven by Ant,
requirement of adding detection of failed tests is brought up. Specifically, it
require us to implement a global counter for all tests, the counter record the
number of failure, once it exceed this limit number, do something.

For example, we have Test case A, B; each has three tests. The whole test begin
with Test A. Assume 2 tests of A failed, the counter is 2; then B begin, 1 test
of B failed. Eventually the counter is 3.

But I did some experiments, seem like each test case will be running in a
separate JVM process. It is quite tricky to share a counter between two process.

I look through the API, maybe this requirement can be done with custom runner,
though we do want change too much and continue to use Ant - Junit runner.

Please give me some hints on this issue. Thanks in advance.

--
Regards.

Yang

Yang,

Can you get all your tests running in a single JVM by adjusting the
"forkmode" parameter to your junit task?  (
http://ant.apache.org/manual/Tasks/junit.html)

    David Saff


On Thu, Jul 12, 2012 at 6:39 AM, yang8628 <feeyungv@...> wrote:

> **
>
>
> Hello experts,
>
> I am working on a project having several Junit 4.10 test cases driven by
> Ant, requirement of adding detection of failed tests is brought up.
> Specifically, it require us to implement a global counter for all tests,
> the counter record the number of failure, once it exceed this limit number,
> do something.
>
> For example, we have Test case A, B; each has three tests. The whole test
> begin with Test A. Assume 2 tests of A failed, the counter is 2; then B
> begin, 1 test of B failed. Eventually the counter is 3.
>
> But I did some experiments, seem like each test case will be running in a
> separate JVM process. It is quite tricky to share a counter between two
> process.
>
> I look through the API, maybe this requirement can be done with custom
> runner, though we do want change too much and continue to use Ant - Junit
> runner.
>
> Please give me some hints on this issue. Thanks in advance.
>
> --
> Regards.
>
> Yang
>
>
>


[Non-text portions of this message have been removed]

David,

Good approach. But I am not sure if I turn this as "once", what kind influence
would bring? I realize the cost of re-create JVM but each JVM process for one
test case seem like a recommended way.

Thanks!

--- In junit@yahoogroups.com, David Saff <saff@...> wrote:
>
> Yang,
>
> Can you get all your tests running in a single JVM by adjusting the
> "forkmode" parameter to your junit task?  (
> http://ant.apache.org/manual/Tasks/junit.html)
>
>    David Saff
>
>
> On Thu, Jul 12, 2012 at 6:39 AM, yang8628 <feeyungv@...> wrote:
>
> > **
> >
> >
> > Hello experts,
> >
> > I am working on a project having several Junit 4.10 test cases driven by
> > Ant, requirement of adding detection of failed tests is brought up.
> > Specifically, it require us to implement a global counter for all tests,
> > the counter record the number of failure, once it exceed this limit number,
> > do something.
> >
> > For example, we have Test case A, B; each has three tests. The whole test
> > begin with Test A. Assume 2 tests of A failed, the counter is 2; then B
> > begin, 1 test of B failed. Eventually the counter is 3.
> >
> > But I did some experiments, seem like each test case will be running in a
> > separate JVM process. It is quite tricky to share a counter between two
> > process.
> >
> > I look through the API, maybe this requirement can be done with custom
> > runner, though we do want change too much and continue to use Ant - Junit
> > runner.
> >
> > Please give me some hints on this issue. Thanks in advance.
> >
> > --
> > Regards.
> >
> > Yang
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>

Hello.

I have a set of packages, let's call them "database-core",
"database-sqlite", "database-postgres". The database-core
package exposes an interface type DB, and the database-sqlite and
database-postgres packages both expose types that implement the DB
interface: DBSqlite and DBPostgres, respectively. I have a huge pile
of tests in the database-sqlite package, and a huge pile of tests in
the database-postgres package.

Now here's the problem: These enormous piles of tests that exercise
these two types are basically identical bar the different specific
DB implementation type.

What I'd like to do is somehow move all of these tests into the
database-core package and have the tests work with the DB interface
type only. The database-sqlite package would then obviously instantiate
a DBSqlite value and somehow pass it as a parameter to these tests. The
database-postgres package would do the same. This would obviously
give some extra confidence that the two implementations have the same
semantics (at least with regards to the parts of the code the tests
end up executing).

What's the correct/simplest way to do this with JUnit 4?

org.junit@... wrote on 15.7.2012 23:51:
> What I'd like to do is somehow move all of these tests into the
> database-core package and have the tests work with the DB interface
> type only. The database-sqlite package would then obviously instantiate
> a DBSqlite value and somehow pass it as a parameter to these tests. The
> database-postgres package would do the same.

You can do that by putting the common tests in an abstract test class
with abstract factory method(s) for creating the concrete implementations.

As an example here is one such abstract test class. Notice the newActors
method:
https://github.com/orfjackal/jumi/blob/master/jumi-actors/src/test/java/fi/jumi/\
actors/ActorsContract.java

Here are the implementations of that class, with some implementation
specific tests:
https://github.com/orfjackal/jumi/blob/master/jumi-actors/src/test/java/fi/jumi/\
actors/MultiThreadedActorsTest.java
https://github.com/orfjackal/jumi/blob/master/jumi-actors/src/test/java/fi/jumi/\
actors/SingleThreadedActorsTest.java

--
Esko Luontola
www.orfjackal.net

On Mon, 16 Jul 2012 14:13:22 +0300
Esko Luontola <esko.luontola@...> wrote:

> org.junit@... wrote on 15.7.2012 23:51:
> > What I'd like to do is somehow move all of these tests into the
> > database-core package and have the tests work with the DB interface
> > type only. The database-sqlite package would then obviously
> > instantiate a DBSqlite value and somehow pass it as a parameter to
> > these tests. The database-postgres package would do the same.
>
> You can do that by putting the common tests in an abstract test class
> with abstract factory method(s) for creating the concrete
> implementations.
>
> As an example here is one such abstract test class. Notice the
> newActors method:
>
https://github.com/orfjackal/jumi/blob/master/jumi-actors/src/test/java/fi/jumi/\
actors/ActorsContract.java
>
> Here are the implementations of that class, with some implementation
> specific tests:
>
https://github.com/orfjackal/jumi/blob/master/jumi-actors/src/test/java/fi/jumi/\
actors/MultiThreadedActorsTest.java
>
https://github.com/orfjackal/jumi/blob/master/jumi-actors/src/test/java/fi/jumi/\
actors/SingleThreadedActorsTest.java
>

Thanks, that's exactly the sort of thing I was looking for (didn't occur
to me that JUnit would handle abstract classes in that manner).

Esko's solution is the most common (and likely best) approach. If you have
a large number of tests, however, it could be tedious and a bit error
prone; you would need to have two subclasses of each test. If you forget to
add a DBSqlite version of your test, you have less code coverage than you
think you do (of course, that's probably the case with your code now).

If all of the tests work with both database types, you might want to try to
indicate which database to use via a system property, and run all of the
tests twice. If you do this, new tests could automatically be run using
both DB implementations. It would mean that your tests would depend on both
implementations, and if you wanted to run the tests in your IDE you would
have to set the system property to specify which implementation to use.

-- Kevin

-- Kevin


On Mon, Jul 16, 2012 at 4:13 AM, Esko Luontola <esko.luontola@...>wrote:

> **
>
>
> org.junit@... wrote on 15.7.2012 23:51:
>
> > What I'd like to do is somehow move all of these tests into the
> > database-core package and have the tests work with the DB interface
> > type only. The database-sqlite package would then obviously instantiate
> > a DBSqlite value and somehow pass it as a parameter to these tests. The
> > database-postgres package would do the same.
>
> You can do that by putting the common tests in an abstract test class
> with abstract factory method(s) for creating the concrete implementations.
>
> As an example here is one such abstract test class. Notice the newActors
> method:
>
>
https://github.com/orfjackal/jumi/blob/master/jumi-actors/src/test/java/fi/jumi/\
actors/ActorsContract.java
>
> Here are the implementations of that class, with some implementation
> specific tests:
>
>
https://github.com/orfjackal/jumi/blob/master/jumi-actors/src/test/java/fi/jumi/\
actors/MultiThreadedActorsTest.java
>
>
https://github.com/orfjackal/jumi/blob/master/jumi-actors/src/test/java/fi/jumi/\
actors/SingleThreadedActorsTest.java
>
> --
> Esko Luontola
> www.orfjackal.net
>
>
>


[Non-text portions of this message have been removed]

Yang,

Sorry for the late response.

I regularly run all my tests in the same JVM.  Depending on your use case,
it might be a fine trade-off.  It should be easy enough to give it a try
and see if it seems to cause any problems.

    David Saff


On Fri, Jul 13, 2012 at 3:29 AM, yang8628 <feeyungv@...> wrote:

> **
>
>
> David,
>
> Good approach. But I am not sure if I turn this as "once", what kind
> influence would bring? I realize the cost of re-create JVM but each JVM
> process for one test case seem like a recommended way.
>
> Thanks!
>
>
> --- In junit@yahoogroups.com, David Saff <saff@...> wrote:
> >
> > Yang,
> >
> > Can you get all your tests running in a single JVM by adjusting the
> > "forkmode" parameter to your junit task? (
> > http://ant.apache.org/manual/Tasks/junit.html)
> >
> > David Saff
> >
> >
> > On Thu, Jul 12, 2012 at 6:39 AM, yang8628 <feeyungv@...> wrote:
> >
> > > **
>
> > >
> > >
> > > Hello experts,
> > >
> > > I am working on a project having several Junit 4.10 test cases driven
> by
> > > Ant, requirement of adding detection of failed tests is brought up.
> > > Specifically, it require us to implement a global counter for all
> tests,
> > > the counter record the number of failure, once it exceed this limit
> number,
> > > do something.
> > >
> > > For example, we have Test case A, B; each has three tests. The whole
> test
> > > begin with Test A. Assume 2 tests of A failed, the counter is 2; then B
> > > begin, 1 test of B failed. Eventually the counter is 3.
> > >
> > > But I did some experiments, seem like each test case will be running
> in a
> > > separate JVM process. It is quite tricky to share a counter between two
> > > process.
> > >
> > > I look through the API, maybe this requirement can be done with custom
> > > runner, though we do want change too much and continue to use Ant -
> Junit
> > > runner.
> > >
> > > Please give me some hints on this issue. Thanks in advance.
> > >
> > > --
> > > Regards.
> > >
> > > Yang
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>


[Non-text portions of this message have been removed]

Maybe have the Ant task produce the JUnit report file and parse that to get
the count of failed tests?

On 17 July 2012 16:44, David Saff <saff@...> wrote:

> Yang,
>
> Sorry for the late response.
>
> I regularly run all my tests in the same JVM.  Depending on your use case,
> it might be a fine trade-off.  It should be easy enough to give it a try
> and see if it seems to cause any problems.
>
>    David Saff
>
>
> On Fri, Jul 13, 2012 at 3:29 AM, yang8628 <feeyungv@...> wrote:
>
> > **
> >
> >
> > David,
> >
> > Good approach. But I am not sure if I turn this as "once", what kind
> > influence would bring? I realize the cost of re-create JVM but each JVM
> > process for one test case seem like a recommended way.
> >
> > Thanks!
> >
> >
> > --- In junit@yahoogroups.com, David Saff <saff@...> wrote:
> > >
> > > Yang,
> > >
> > > Can you get all your tests running in a single JVM by adjusting the
> > > "forkmode" parameter to your junit task? (
> > > http://ant.apache.org/manual/Tasks/junit.html)
> > >
> > > David Saff
> > >
> > >
> > > On Thu, Jul 12, 2012 at 6:39 AM, yang8628 <feeyungv@...> wrote:
> > >
> > > > **
> >
> > > >
> > > >
> > > > Hello experts,
> > > >
> > > > I am working on a project having several Junit 4.10 test cases driven
> > by
> > > > Ant, requirement of adding detection of failed tests is brought up.
> > > > Specifically, it require us to implement a global counter for all
> > tests,
> > > > the counter record the number of failure, once it exceed this limit
> > number,
> > > > do something.
> > > >
> > > > For example, we have Test case A, B; each has three tests. The whole
> > test
> > > > begin with Test A. Assume 2 tests of A failed, the counter is 2;
> then B
> > > > begin, 1 test of B failed. Eventually the counter is 3.
> > > >
> > > > But I did some experiments, seem like each test case will be running
> > in a
> > > > separate JVM process. It is quite tricky to share a counter between
> two
> > > > process.
> > > >
> > > > I look through the API, maybe this requirement can be done with
> custom
> > > > runner, though we do want change too much and continue to use Ant -
> > Junit
> > > > runner.
> > > >
> > > > Please give me some hints on this issue. Thanks in advance.
> > > >
> > > > --
> > > > Regards.
> > > >
> > > > Yang
> > > >
> > > >
> > > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

--- In junit@yahoogroups.com, <org.junit@...> wrote:
>
> Hello.
>
> I have a set of packages, let's call them "database-core",
> "database-sqlite", "database-postgres". The database-core
> package exposes an interface type DB, and the database-sqlite and
> database-postgres packages both expose types that implement the DB
> interface: DBSqlite and DBPostgres, respectively. I have a huge pile
> of tests in the database-sqlite package, and a huge pile of tests in
> the database-postgres package.
>
> Now here's the problem: These enormous piles of tests that exercise
> these two types are basically identical bar the different specific
> DB implementation type.
>

To solve your problem is one of the major purposes of CallbackParams:
http://callbackparams.org

With CallbackParams you can have enum-classes provide parameter-values. In your
case I can suggest an enum-class "DBFactory", which has one constant "POSTGRES"
to provide the DBPostgres implementation and another constant "SQLITE" to
provide the DBSqlite implementation:

public enum DBFactory {

     POSTGRES(new DBPostgres()),
     SQLITE(new DBSqlite());

     private DB db;

     private DBFactory(DB db) { this.db = db; }

     public DB getDB() { return this.db; }
}

You can then have your test-classes use the JUnit-runner CallbackParamsRunner
...

http://callbackparams.org/project/api-javadoc/org/callbackparams/junit4/Callback\
ParamsRunner.html

... and the field-annotation @ParameterizedValue ...

http://callbackparams.org/project/api-javadoc/org/callbackparams/ParameterizedVa\
lue.html

... to parameterize your "common" test-classes:

@RunWith(CallbackParamsRunner.class)
public ACommonTest {

     @ParameterizedValue public DBFactory database;

     final private DB db = database.getDB();

     @Test public void testMethod() { /* test-code */ }
}

The test-class ACommonTest will be run twice - once for each constant in
DBFactory. The field database will be injected with the enum-constant POSTGRES
on the first run and SQLITE on the second run.

Your tests will get proper names:

  - testMethod[database=POSTGRES]
  - testMethod[database=SQLITE]

One of the major objectives for CallbackParams is to simplify future
maintenance, such as when you decide to support another database, such as
Oracle. All you need to do for the tests is to add another constant "ORACLE" to
your enum-class - and all of your test-classes will suddenly test Oracle as
well.

Good luck /Henrik

After last summer's "Green Lantern" movie, my inner unit-testing
evangelist merged with my inner comics geek, and channelled the
Green-Lantern-themed "Junit Oath".

Now you can see it in it's full glory at: http://junitoath.caucus.com

Enjoy.

David,

Thanks for your reply. I tired several methods, seem like it is better to
solve outside of Junit tests.

On Wed, Jul 18, 2012 at 4:44 AM, David Saff <saff@...> wrote:

> Yang,
>
> Sorry for the late response.
>
> I regularly run all my tests in the same JVM.  Depending on your use case,
> it might be a fine trade-off.  It should be easy enough to give it a try
> and see if it seems to cause any problems.
>
>    David Saff
>
>
> On Fri, Jul 13, 2012 at 3:29 AM, yang8628 <feeyungv@...> wrote:
>
> > **
> >
> >
> > David,
> >
> > Good approach. But I am not sure if I turn this as "once", what kind
> > influence would bring? I realize the cost of re-create JVM but each JVM
> > process for one test case seem like a recommended way.
> >
> > Thanks!
> >
> >
> > --- In junit@yahoogroups.com, David Saff <saff@...> wrote:
> > >
> > > Yang,
> > >
> > > Can you get all your tests running in a single JVM by adjusting the
> > > "forkmode" parameter to your junit task? (
> > > http://ant.apache.org/manual/Tasks/junit.html)
> > >
> > > David Saff
> > >
> > >
> > > On Thu, Jul 12, 2012 at 6:39 AM, yang8628 <feeyungv@...> wrote:
> > >
> > > > **
> >
> > > >
> > > >
> > > > Hello experts,
> > > >
> > > > I am working on a project having several Junit 4.10 test cases driven
> > by
> > > > Ant, requirement of adding detection of failed tests is brought up.
> > > > Specifically, it require us to implement a global counter for all
> > tests,
> > > > the counter record the number of failure, once it exceed this limit
> > number,
> > > > do something.
> > > >
> > > > For example, we have Test case A, B; each has three tests. The whole
> > test
> > > > begin with Test A. Assume 2 tests of A failed, the counter is 2;
> then B
> > > > begin, 1 test of B failed. Eventually the counter is 3.
> > > >
> > > > But I did some experiments, seem like each test case will be running
> > in a
> > > > separate JVM process. It is quite tricky to share a counter between
> two
> > > > process.
> > > >
> > > > I look through the API, maybe this requirement can be done with
> custom
> > > > runner, though we do want change too much and continue to use Ant -
> > Junit
> > > > runner.
> > > >
> > > > Please give me some hints on this issue. Thanks in advance.
> > > >
> > > > --
> > > > Regards.
> > > >
> > > > Yang
> > > >
> > > >
> > > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


--
Regards.

Yang


[Non-text portions of this message have been removed]

Hello

I want to run JUnit inside a BlackBerry Java 5.0 application. My code needs to
be class and source compatible with Java 1.3.

What version of JUnit can I use and where can I download this version? I had a
look on GitHub, only 4. release is available.

Hendré

JUnit 3.7 and upwards is available in Maven Central:
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22junit%22%20AND%20a%3A%22junit\
%22

bakgat73 wrote on 26.7.2012 17:45:
> Hello
>
> I want to run JUnit inside a BlackBerry Java 5.0 application. My code
> needs to be class and source compatible with Java 1.3.
>
> What version of JUnit can I use and where can I download this version? I
> had a look on GitHub, only 4. release is available.
>
> Hendré
>

--
Esko Luontola
www.orfjackal.net

I want to adapt JUnit for use in the BlackBerry Java Development Environment.

The BlackBerry Java JDE 5.0 is source and class compatible with Java 1.3 and is
based on Java ME. There are no support for AWT, Swing, Reflection or Annotations
in the BlackBerry 5.0 JDK.

From my initial investigation, removing the AWT and Swing packages are not a
problem, however reflection seems to be core to how JUnit function.

What version of JUnit must I start with and is it worth the effort to replace
the reflection code?

Are there anyone that want's to collaborate on this project?

Hendré

bakgat73 wrote on 27.7.2012 17:04:
>  From my initial investigation, removing the AWT and Swing packages are
> not a problem, however reflection seems to be core to how JUnit function.

Even though your production code can't use reflection, it should be
possible to use it in tests if you can run the tests on your desktop
using the standard JRE. With most build tools this means keeping the
production and the test code in different modules, so that you can
configure them different JDKs.

If that is not possible, then here are some ideas:

Making JUnit uses reflection for finding out all test methods from a
class, and without reflection it would require lots of boilerplate to
explicitly call all those methods. An option would be to create your own
framework (maybe reusing JUnit's assertions) or start based on a
framework which uses reflection very little.

For example my Specsy testing framework (http://specsy.org/) uses
reflection only when instantiating the test class [1], because the tests
are declared using closures (in the Java version they will be anonymous
inner classes, see this draft [2] on the syntax). Hard-coding that
instatiation would require only a single-method factory class for each
test class.

In the near future I'll rewrite Specsy in Java (it will be called Specsy
2), and create thin frontends at least for Java, Scala and Groovy. After
that it might be possible to fork it and create a reflection-free Java
1.3 compatible version. Specsy 2 and the Jumi test runner
(http://jumi.fi/), which it will use, will require Java 7, but also Jumi
uses very little reflection so it might be possible to fork and extract
a limited Java 1.3 compatible version of it.

Creating your own testing framework is actually quite easy, if you just
keep the scope small. Without support for running tests in parallel, it
is possible to implement the same programming model as in Specsy, plus a
small test runner for it, in 10-50 hours. I wrote NanoSpec.go [3] in 6
hours (about 300 LOC production code) and it uses Go's minimal test
runner [4] (about 400 LOC), which would not take much longer to
implement either.

[1]
https://github.com/orfjackal/specsy/blob/b9fa91cb70d9a09e74c2e71984b2da95c5c8248\
1/src/main/scala/net/orfjackal/specsy/core/SpecClassRunner.scala#L18
[2]
https://github.com/orfjackal/specsy/blob/46ad34f93c8d1b343db601bf5200c9a1ef08570\
6/specsy-core/src/test/java/org/specsy/examples/JavaStackSpecDraft4.java
[3] https://github.com/orfjackal/nanospec.go
[4] http://golang.org/pkg/testing/

--
Esko Luontola
www.orfjackal.net

Hi ,
  I see that Junit THeories have been in experimental state for quite a long. Is
there any roadmap to move them out of the experimental state?
It is really helpful for us in our project, but we are a bit skeptical to use
experimental features in our code base. If there's a road map that says it will
be part of the junit core soon, that will be sufficient.

Thanks,
  Anuj

Anuj,

I don't have an official road map document.  I can tell you that
maintaining the current functionality of Theories is important to the team.
  Right now, we haven't been putting high priority on moving code from
experimental into core.

Hey, all: are there other list members who would find their lives easier if
Theories was moved to core?

    David Saff


On Tue, Jul 31, 2012 at 5:45 AM, Anuj <anujkumar1516@...> wrote:

> **
>
>
> Hi ,
> I see that Junit THeories have been in experimental state for quite a
> long. Is there any roadmap to move them out of the experimental state?
> It is really helpful for us in our project, but we are a bit skeptical to
> use experimental features in our code base. If there's a road map that says
> it will be part of the junit core soon, that will be sufficient.
>
> Thanks,
> Anuj
>
>
>


[Non-text portions of this message have been removed]

Hi folks,

I am glad to announce that there is a new JUnit snapshot available through
GitHub and Maven. It includes/references the recently released Hamcrest 1.3.

It would help us a great deal if some of you could give it a try and provide
feedback. In particular, if you make heavy use of assertThat and Hamcrest
matchers, please report any incompatibilities that you might experience.

Cheers, Marc

I tried to override my branch my way using rebase and i completely broke it.
Later on the push cmd did not work saying that the branch is up-to-date and
nothing to push :(

Can you please provide commands to override a branch from KentBeck/junit?

thx, Tibor

I'd not tried this recently, so I've just had a go at rebasing a branch
in my fork:

git clone git@...:nealeoc/junit.git
cd junit/
git branch -r
git checkout -t -b local-complex-rules origin/complex-rules

git remote add upstream git@...:KentBeck/junit.git
git fetch upstream
git branch -r
git rebase upstream/master

This then unsurprisingly fails to rebase, as my branch is out of date,
so I need to fix it up, and then do.

git add -u
git rebase --continue

And then I can

git push



On 08/08/12 01:17, tibord47 wrote:
> I tried to override my branch my way using rebase and i completely broke it.
Later on the push cmd did not work saying that the branch is up-to-date and
nothing to push :(
>
> Can you please provide commands to override a branch from KentBeck/junit?
>
> thx, Tibor
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>