Improve testing and structure of example code about java HOT 19 CLOSED

I'm not paying much attention these days, but from what I can see I think @jtigger wants to improve testing somehow. A good idea but I guess it'll have to be done more systematically if we don't want to break the build (and confuse users).

from java.

Yepp, I'll reopen this so we can discuss how that should be done.

from java.

One thing to note is that if a file is not named something with example, it will be delivered as part of the problem when someone says exercism fetch.

If we want to run the tests as part of the build, we can consider some sort of build script that copies the relevant files to a temporary directory and renames what it needs to.

I suggest running it in a temporary directory rather than in place, because I don't want to risk committing the example solution with the incorrect name accidentally, since that would start delivering the solution along with the problem.

from java.

Wow! Apologies for the sloppy process. I could have sworn I checked the CI build before walking away. Clearly not. :(

... and I should have (at a minimum) run ./bin/configlet .

from java.

Regarding the question at hand. I read through the x-api code to see how examples are filtered. will omit any file who's pathname contains "example". So, the a file with a path src/example/Anything.any will not be delivered.

The configlet uses a slightly different rule: that the filename itself matches the pattern [Ee]xample.

I was experimenting with a directory structure that not only was easier to configure for the build (the convention in modern Java projects — initiated by Maven and now used by Gradle — is to put all source under the ./src directory; the sub-directories naming the usage (typically main for the product, test for unit tests, integration-test, and so on); but also to make it easier to contribute.

"Easier to contribute" in this sense: all one needs to do to configure their classpath is load the project from the gradle build and then add the source root ./src/example and away they go. I have yet to meet a Java developer who doesn't use an IDE. Configuring the classpath to include the root of the project is problematic because it includes all the sub-directories.

I propose that the configlet be made to behave like the x-api code and filter anything that has "example" (case-insensitive) in the path.

from java.

Aaah. This makes sense. Configlet can be improved--give me a moment.

from java.

OK, fixed in exercism/configlet@27424c1

I've cut a new release. If you re-fetch configlet, it should now allow /example/i in the path.

https://github.com/exercism/configlet/releases/tag/v1.0.2

from java.

/me is gobsmacked. Just like that?!? Hot!

from java.

@sit — what do you think of the idea of a track CI that runs the tests against the example for all exercises?

I don't have a master plan, per se. Adding this other source root was my attempt at a first move toward automation. Next step would be to get that test running in CI. Larger scope, either each exercise is built independently ... or we build a single classpath that spans all the exercises (will we ever have classname collisions)? and just run all the unit tests in one fell swoop... or some other way?

from java.

You will not have class name collisions, as far as I know. The slug (problem directory) is unique; the names of the classes should probably follow the name of the problem directory. This was not always the case in Ruby, but automation became easier when we could assume that it was true, so we changed it.

from java.

I think running the tests against the example code is a good idea.

If memory serves, I made each exercise a separate Gradle project so you can download each one independently and run it. I think that is consistent with how other languages work as well.

We'd need to figure out a way to get something so that the configlet runs some script in each exercise directory to validate it and the configlet could just check the exit code to make sure things are cool, without having to know that in Java you run "./gradlew build" vs something else in another language.

Does that sound right @kytrinyx?

from java.

More or less :) Configlet is separate from this, it's basic linting of the project structure.

Each language has had to solve CI differently. At the highest level we need a command that we can put into the .travis.yml file. If the command exits with 0, the build passes.

For some (e.g. Go: https://github.com/exercism/xgo/blob/master/.travis.yml#L10) it's just a matter of calling the usual test suite. For others (e.g. Ruby: https://github.com/exercism/xruby/blob/master/.travis.yml#L15) we had to write a custom task (https://github.com/exercism/xruby/blob/master/Makefile)

So if we have some sort of bash script that checks each test suite against the example and exits with a proper status code, then we're good to go.

from java.

I did a little learning around this while validating a pull request. Simply adding these two lines:

sourceSets { example { } }
dependencies { testCompile sourceSets.example.output }

will automatically compile and include the "example" source dir. It will also ignore this config if the said directory is absent (read: one build.gradle will work for both exercists and track maintainers, alike with no modification and no conditional logic).

On a branch, I'll push both this configuration and restructure each problem to conform to the Maven directory structure convention (and Java convention — most notably that a public class must be defined in a file of the same name as that class).

from java.

Hmmm... of course, if we have a partial implementation in src/main/java (e.g. as in the "ETL" problem), the compilation fails because we have two definitions for the same class. 😝

hmmm....

from java.

Aw shucks! :)

from java.

I fixed it! :)

The trick was to refined the "main" source set to point to ./src/example/java (when it normally points to ./src/main/java. The one caveat is that any "starter" source that's required to make a submission work ("triangle" has a couple of such source files) needs to be included. For now,I've soft-linked those files from the main source into the example source.

At this point, the CI build runs the tests against the example code: all green.

There's one verification left before I merge this back into master: ensure that delivered problems still work for exercists.

Before I call this done, I feel the need to update the README.md to make the setup and usage explicit.

from java.

Updating the README would be a real help, indeed. I've found that on exercism I'm regularly referring to documentation that I wrote (or kicking myself because I didn't write any)... it's just so long between each time I have to do certain things.

from java.

Already paying back: https://travis-ci.org/exercism/xjava/builds/80567549 !!!

from java.

Winning!

from java.