Java: Should we use a test generator?

Created on 2 Oct 2018  路  6Comments  路  Source: exercism/java

As suggested by @beatbrot:

How do you think about creating Unit-Tests out of the canonical-data.json?
I could work on that, If you want me to :)

What do we think about creating an automatic test generator @exercism/java? 馃檪

question

Most helpful comment

Personally I think creating a test generator would be an interesting task and it could make it easier to maintain the Java track in future.

However, most of our good first patch issues and hacktoberfest issues come from updating the tests. I think it's important we have ways for new people to contribute so if adding a test generator would make that more difficult then I would be less keen to add one.

And with our current setup with version files and script to check if they're up to date, maintaining the tests isn't too difficult 馃檪

Also as @sjwarner-bp mentioned, it would make it more difficult to deviate from the current suites. I don't think we do that often, but we do at least once and it's nice to have the option.

So I think there would be pros and cons to adding a test generator 馃檪 It might be worth looking at any other tracks (e.g. F#) to see how theirs works?

All 6 comments

That would be interesting. I think the F# track have had good success with this.

Depends how much we already deviate from the current suites though :thinking:

Personally I think creating a test generator would be an interesting task and it could make it easier to maintain the Java track in future.

However, most of our good first patch issues and hacktoberfest issues come from updating the tests. I think it's important we have ways for new people to contribute so if adding a test generator would make that more difficult then I would be less keen to add one.

And with our current setup with version files and script to check if they're up to date, maintaining the tests isn't too difficult 馃檪

Also as @sjwarner-bp mentioned, it would make it more difficult to deviate from the current suites. I don't think we do that often, but we do at least once and it's nice to have the option.

So I think there would be pros and cons to adding a test generator 馃檪 It might be worth looking at any other tracks (e.g. F#) to see how theirs works?

Question is also: Do we want to have a generator that generates actual Java Code with @Test methods?

Or would we rather want to have a @Test-Method that processes the json-File?

Personally, I would say a test generator would be quite difficult to make (as mentioned here).

Would it be worth making a test generator? Essentially we would be making a thing to maintain the tests. Instead of us maintaining the tests we would have to maintain the thing that maintains the tests.

Like @FridaTveit mentioned, other tracks have test generators which would be hugely beneficial to look at.

Another question that's important is what language would we build the test generator in? At first one might assume Java, but since it's not an exercise, it doesn't have to be written in Java. There's probably better languages to write it in. The tests use bash to run.

Question is also: Do we want to have a generator that generates actual Java Code with @test methods?

Or would we rather want to have a @Test-Method that processes the json-File?

@beatbrot how would it process the json file? I imagine a true "test generator" would generate actual java code, but I'm curious to hear your thoughts on a json processor

@beatbrot how would it process the json file? I imagine a true "test generator" would generate actual java code, but I'm curious to hear your thoughts on a json processor

Well, another alternative is to let an abstract class handle the loading from the JSON-File. For each entry in the JSON file, the class would call an abstract method test(...) that has to return the value calculated by the solution. This is then compared to what was expected by the json-file.

The abstract class should make use of generics similar to how java.util.function.Function does it. We might also have a BiAbstractTest, that accepts two input parameters.

I agree that this class would be rather complicated to implement, considering that these are beginner exercises, however: If the test-writer does not care about the internals of this abstract class, creating tests would be much quicker!

Closing this as an abandoned idea. Since we can often create better assertions ourselves manually for each test class, I am generally against this approach anyway (it is also likely to require more work from the maintainers).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

stkent picture stkent  路  5Comments

lemoncurry picture lemoncurry  路  3Comments

dawcars picture dawcars  路  7Comments

ErikSchierboom picture ErikSchierboom  路  3Comments

rvictorino picture rvictorino  路  5Comments