Table-driven testing in JUnit with TableTest

[nchaugen]

First off all, thank you @junit-team for your great work in developing and maintaining JUnit.

I am a long-time fan of using tables to drive tests, ever since being introduced to Ward Cunningham’s Fit Framework 20 years ago.

Having used Spock Framework for table-driven testing in recent projects, I found that not all Java and Kotlin developers got comfortable with the Groovy-ness of it.

Based on this experience, plus some ideas for how to further improve support for table-driven testing, I set out to create an alternative based on JUnit.

The result is TableTest. I also wrote a couple of short blog posts that introduce table-driven testing and TableTest, and I created a plugin for IntelliJ IDEA to help with auto formatting, colouring and syntax.

I have received good feedback from people who have looked into it and started using it in their projects.

One question I get is if it would be possible to make TableTest built-in to JUnit. Personally I would love that as it would make table-driven testing available to a lot of programmers.

So I wanted to ask your thoughts on this. If you think it is worth looking into, I would be happy to discuss how we could approach it, and also to do the necessary adaptations if we decide to move forward.

Thanks!

[marcphilipp]

First of all, thanks for reaching out! I think TableTest looks very useful. There is quite a bit of overlap with regular @ParameterizedTests with @CsvSource, isn't there? It looks like you were able to reuse quite a bit of the framework, including JUnit's converter support (at least as a fallback). We're currently thinking about making that extensible (see ). If you have a chance, it would be great to get your feedback on that work so it will ideally be useful to you as well.

One question I get is if it would be possible to make TableTest built-in to JUnit. Personally I would love that as it would make table-driven testing available to a lot of programmers.

So I wanted to ask your thoughts on this. If you think it is worth looking into, I would be happy to discuss how we could approach it, and also to do the necessary adaptations if we decide to move forward.

We can certainly discuss it! Please note that we're currently very busy with the upcoming 6.0 release so it will take even longer than usual. I'll add it to our discussion backlog.

[nchaugen]

Thank you for the swift response!

You are right that @TableTest is overlapping with @ParamerizedTest with @CsvSource. That is what I would be using previously for table-driven tests in JUnit.

I would say the main improvements @TableTest brings are readability, support for collection types, and the ability use factory methods for custom, automatic conversion to method parameter types.

I also find that the less verbose annotation setup and the scenario column adds to the developer comfort.

A more extensible converter service sounds helpful to this kind of string-based value providers for parameterized tests. I will have a look. Is this work happening in PR #4219?

Happy to contribute in a discussion when you have the time.

Looking forward to the 6.0 release!

[marcphilipp]

Is this work happening in PR #4219?

Yes, that's the one. 👍