Please provide vanilla samples about junit5-samples HOT 19 CLOSED

"Vanilla" as w/o a build tool? That's probably a good idea. Just some (3, or 4 now) jars and a main and a test class along with some shell scripts to build and execute them. Structured like:

+ deps-compiletime/
  - apiguardian-1.0.0.jar
  - junit-jupiter-api-5.0.0.jar
  - junit-platform-commons-1.0.0.jar
  - opentest4-1.0.0.jar
+ deps-runtime/
  - junit-platform-console-standalone-1.0.0.jar (or each jar needed to launch a test run w/ Jupiter?)
+ src
  + main
    + java
       + foo
          - Foo.java
+ src
  + test
    + java
       + foo
          - FooTests.java
- build.bat
- build.sh
- run.bat
- run.sh
- test.bat
- test.sh

Does this sample look more vanilla?

from junit5-samples.

Sorry, no. Vanilla as only showing a plain JUnit5 use case. The current sample shows how you can run your JUnit4 tests and other scenario. I think a sample that shows the "standard case" and only that will help users to understand what they need to get started.

from junit5-samples.

Ah. Remove other code and configuration setup and only keep "FirstTests.java"?

from junit5-samples.

And enhance "FirstTests" with more examples from the user-guide?

from junit5-samples.

Split the current sample basically, yes. I think there are users that want to know what it takes to write tests with JUnit5 (and only that). And they are users wondering how they can run their existing tests on the new platform. Right now, the two are combined which brings noise in each scenario.

I understand that JUnit is more modular and that's awesome but there should be a "shortcut" for the regular case IMO.

from junit5-samples.

JUnit 5 "Jupiter-only" Gradle build script could look like:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'org.junit.platform:junit-platform-gradle-plugin:1.0.0'
    }
}

apply plugin: 'java'
apply plugin: 'org.junit.platform.gradle.plugin'

repositories {
    mavenCentral()
}

dependencies {
    testCompile group: 'org.junit.jupiter', name: 'junit-jupiter-api', version: '5.0.0'

    testRuntime group: 'org.junit.jupiter', name: 'junit-jupiter-engine', version: '5.0.0'
}

Now, the Calculator application and the FirstTests go in src/[main|test]/java...

from junit5-samples.

Here are the resolved external dependencies from the minimal Gradle script above, using Intellij IDEA 2017.2.4:

from junit5-samples.

Sorry I am not following why you're pasting this here.

from junit5-samples.

Just to ensure, that we are on the same road regarding what a vanilla sample looks like.

from junit5-samples.

You tell me, I am not an expert in JUnit 5 :)

That looks Vanilla for Gradle to me even though I am not sure a beginner cares between the testCompile and testRuntime scope (a single entry would be less noise IMO). Having said that, I can certainly appreciate that the sample uses the right scope (I opened a PR for that myself a few days ago!)

from junit5-samples.

@snicoll,

Split the current sample basically, yes. I think there are users that want to know what it takes to write tests with JUnit5 (and only that). And they are users wondering how they can run their existing tests on the new platform. Right now, the two are combined which brings noise in each scenario.

I hear you, and I totally agree: we should have vanilla examples demonstrating (literally) the bare minimum to...

1. set up a JUnit Jupiter based Gradle project that can also be imported into IDEA or Eclipse
2. set up a JUnit Jupiter based Maven project that can also be imported into IDEA or Eclipse

from junit5-samples.

You tell me, I am not an expert in JUnit 5 :)

I can confirm that that's about as vanilla as it gets for JUnit Jupiter and Gradle. 😉

That looks Vanilla for Gradle to me even though I am not sure a beginner cares between the testCompile and testRuntime scope (a single entry would be less noise IMO). Having said that, I can certainly appreciate that the sample uses the right scope (I opened a PR for that myself a few days ago!)

I agree that a beginner probably doesn't care about that, but I also think the JUnit Team should demonstrate the right way to do it (even if it's an additional dependency in the POM or Gradle build script).

from junit5-samples.

I also think the JUnit Team should demonstrate the right way to do it

I agree, I just wrote that myself. It's a different story for Maven though and I still think a single dependency would be better.

from junit5-samples.

Partly addressed with a98326b show-casing a minimal Gradle setup.

from junit5-samples.

Thanks for adding the samples.

As this issue is closed now and I didn't get feedback on the one entry proposal. Can you please confirm that vanilla means I have to manage two versions to get started? You do not foresee another way to handle this for the user?

from junit5-samples.

[...] It's a different story for Maven though and I still think a single dependency would be better.

Why is it a different story? Because there's only a "test" scope?

It could be possible to only refer to the "jupiter-engine" artifact and let Maven (and Gradle?) sort out the depedency to "jupiter-api" and all other needed artifacts as well.

from junit5-samples.

Why is it a different story? Because there's only a "test" scope?

Yes.

from junit5-samples.

Looks like #40 compiles. Will merge the "reduction" PR soon.

Thanks for being patient with me here. :)

from junit5-samples.

With d4441db finally ... pristine Maven vanilla flavor. 🍦

from junit5-samples.