mscharhag / oleaster Goto Github PK

ATM JUnit depedency is defined in parent and Oleaster Runner pom.xml?

Build Oleaster on Travis-CI

I think if the method only output the descriptive string it would allow for more freedom how people can choose to describe their examples

How do I run tests on code that runs on other threads?

Something like:

expect(5).toBeGreaterThan(2);
expect(5).toBeSmallerThan(10);
expect(5).toBeBetween(2, 10);

For example:

expect(list).toContain("foo");
expect(map).toContainKey("foo");
expect(list).toBeEmpty();
...

Provide a String matcher that supports common string checks:

expect("foo").toEqual("foo");
expect("foo").toMatch(regex);
expect("foo").toStartWith("fo");
expect("foo").toContain("o");

The default JUnit runner isolate tests in a way that every test gets executed with a new test-case instance. This ensures a fresh fixture instance for each test, even if the developer uses an implicit setup shortcut.

It seems to me that Oleaster tests work always with the same fixture in such a case. This is because the test-case instance is reused for all test runs (see snippet below for a better understanding of the use-case).

This behavior might lead to problems which are difficult to understand. Although I am not a particular friend of this setup practice, I doubt that people will follow a do-not-use-this-kind-of-implicit-setup convention. Maybe it would be better to ensure this kind of isolation as JUnit does by default.

@RunWith( OleasterRunner.class )
public class OleasterTest {

  Object fixture = new Object();

  {  
    it( "first", () -> {
      System.out.println( "first: " + fixture.hashCode() );
    } );

    it( "second", () -> {
      System.out.println( "second: " + fixture.hashCode() );
    } );
  }
}

I'd like to have something like

describe("My test", () -> {

        expect(MyException.class, () -> {
            throw new MyException();
        });

        expect(MyException.class, "should throw an exception", () -> {
            throw new MyException();
        });

When running a package of test classes in IntelliJ, suite descriptions seem to be duplicated. E.g. when running the tests in the 'oet.wouter.scanner.api' package the result is as follows:

Although I didn't test it I assume this behavior is also present in other IDE's.

Just want to say a huge thank you for this library. Coming from developing javascript for some time, this really makes java testing a treat, compared to standard jUnit.

I would star it 10 times if I could.

Will definitely send any PRs for any issues/improvements I find down the track!

I'd like to use Oleaster in an OSGi-based project, but the JAR does currently not have an OSGi manifest. This can be easily added either in a hard-coded fashion by adding a src/main/resources/META-INF/MANIFEST.MF file or by adding a build step to the POM that generates a manifest automatically.
If there is a chance that such a change could get released to Maven Central soon, I'm happy to make a pull request with the necessary changes.

At the moment it() can be used outside describe(). This should cause an error.

Split documentation up for runner / matcher libraries.

Robolectric is the default android test runner. I am trying to use Oleaster on android and so wrote a test runner. Just wanted to see if you will be open for a PR. It will be a separate module and the main code will not be affected.

Something like:

expect(date).toBeBefore(otherDate);
expect(date).toBeAfter(otherDate);
expect(date).toBeBetween(first, second);
...

It would be nice to be able to write:

expect(someObject).toBeInstanceOf(String.class);

If the method only echoed the descriptive string parameter the problem would be solved. Pretty sure Jasmine does it like this as well.

Thank you for the library, I am quite glad with it.
Unfortunately I cannot 100% migrate my JUnit tests without hacks.

For some reasons I need to get the current test name etc.
It would be great to expose some info at runtime.
While using JUnit, I used TestRules but they are not currently supported (#17)

When I have on my BaseTest that all the tests extend

@RunWith(OleasterRunner.class)
@SpringBootTest
@Ignore
public class BaseTest {

    @Autowired
    protected DbC conf;
    [...]
}

it doesn't initialize Spring Boot ApplicationContext so Autowired annotated properties are not injected as expected

similarly beforeSuite() and afterSuite() needed.

When having more than one beforeEach block like below, it runs them in reversed order. This is different from jasmine's behavior. It seems afterEach gets executed in order.

@RunWith(OleasterRunner.class)
public class OleasterTest {

  String lhs;
  String rhs;

  String target;

  {
    beforeEach(() -> {
      System.out.println("arrange");
      lhs = "a";
      rhs = "b";
    });

    beforeEach(() -> {
      System.out.println("act");
      target = lhs + rhs;
    });

    it("should be added", () -> {
      expect(target).toEqual(lhs + rhs);
    });
  }
}

This will print out act then arrange, and test is failing unexpectedly.

When writing unit tests in plain old JUnit, at least in an IDEA it is possible to run a single test. Currently this is not the case for oleaster afaik. Now I understand that this is partly an IDEA thing and this might be seen as out-of-scope for this project. However I would suggest the following:

In Jasmine they have the 'focused specs' concept, where you can prefix an it with the letter f, to run only that block, or prefix a describe with the letter f to run only that describe block.

Focussed it

describe("The Product class", () -> {
    fit("should be awesome", () -> { // <-- only this it will be ran, every other will be skipped
        Product p = new Product();
        expect(p.areYouAwesome()).toBeTrue();
    });

    describe("nested thing", () -> {
      it("should do 1", () -> {
        expect(true).toBeTrue();
      });

      it("should do 2", () -> {
        expect(false).toBeFalse();
      });
    });
});

Focussed describe

describe("The Product class", () -> {
    it("should be awesome", () -> {
        Product p = new Product();
        expect(p.areYouAwesome()).toBeTrue();
    });

    fdescribe("nested thing", () -> { // <-- only the it's in this block will be ran, every other will be skipped
      it("should do 1", () -> {
        expect(true).toBeTrue();
      });

      it("should do 2", () -> {
        expect(false).toBeFalse();
      });
    });
});

An interesting alternative, which I prefer since it's more readable, is Mocha (which is a Jasmine alternative), which used the 'exclusive' and 'inclusive' concepts:

exclusive it

describe("The Product class", () -> {
    it.only("should be awesome", () -> { // <-- only this it will be ran, every other will be skipped
        Product p = new Product();
        expect(p.areYouAwesome()).toBeTrue();
    });

    describe("nested thing", () -> {
      it("should do 1", () -> {
        expect(true).toBeTrue();
      });

      it("should do 2", () -> {
        expect(false).toBeFalse();
      });
    });
});

exclusive describe

describe("The Product class", () -> {
    it("should be awesome", () -> {
        Product p = new Product();
        expect(p.areYouAwesome()).toBeTrue();
    });

    describe.only("nested thing", () -> { // <-- only the it's in this block will be ran, every other will be skipped
      it("should do 1", () -> {
        expect(true).toBeTrue();
      });

      it("should do 2", () -> {
        expect(false).toBeFalse();
      });
    });
});

Inclusion

describe("The Product class", () -> {
    it.skip("should be awesome", () -> { // <-- run everything except this it
        Product p = new Product();
        expect(p.areYouAwesome()).toBeTrue();
    });

    describe("nested thing", () -> {
      it("should do 1", () -> {
        expect(true).toBeTrue();
      });

      it("should do 2", () -> {
        expect(false).toBeFalse();
      });
    });
});

describe("The Product class", () -> {
    it("should be awesome", () -> {
        Product p = new Product();
        expect(p.areYouAwesome()).toBeTrue();
    });

    describe.skip("nested thing", () -> { // <-- run everything except this block
      it("should do 1", () -> {
        expect(true).toBeTrue();
      });

      it("should do 2", () -> {
        expect(false).toBeFalse();
      });
    });
});

In ExpcetionMatcher:

Expectations.expectTrue(expectedMessage.equals(exceptionMessage),
                "Expected exception message '%s' but was '%s'", exceptionMessage, exceptionMessage);

exceptionMessage is passed to times as format paramter. One of those parameters should be expectedMessage instead of exceptionMessage.

Javadoc comments are in general not very comprehensive (if they exist) and should be improved.

Something like:

expect(1.00001).toBeCloseTo(1, 0.001)

or

expect(1.00001).toBeCloseTo(1).withDelta(0.001)

Add the ability to use Jasmine like Matchers for building assertions.
At least a matcher for testing exceptions is required because Oleaster is incompatible to JUnits exception testing utilities (@test(expected=MyException.class)).

It would probably be a good idea to have rules support available to avoid reinventing the wheel - if possible. However I could not come up with an idea of how to support in particular rules that evaluate additional annotations on test methods.