[Epic] Track improvement checklist

[dector]

Things I would suggest to do:

• Check open PRs and take some actions for each (close/merge/define action points).
• Check open issues and take some actions for each (close/define action points).
• Check exercises and fix missing source files.
• Update base template (implemented here):
  • Update gradle.
  • _(Requires further discussion) Use Jupiter (JUnit5) as a testing platform. _
  • (Requires further discussion) Use TestOrder + fail-fast strategy to improve testing experience for students.
• Fix issues from report.
• I'm exploring other ways to improve tooling for exercises (e.g. I believe it's possible to make testing more lightweight without Gradle).

[dector]

cc: @mikegehard

What do you think?

[mikegehard]

Thanks @dector

I totally agree with the first 3 bullet items. I would love to get to a place where both PRs and issues are empty.

Updating gradle is another good one.

I'd like to talk more about Jupiter and TestOrder. I'm unfamiliar with Jupiter and would love to understand your thoughts on improving the testing experience.

[dector]

I'd like to talk more about Jupiter and TestOrder. I'm unfamiliar with Jupiter and would love to understand your thoughts on improving the testing experience.

I'm actually talking about Junit 5. :) You can read more about it here.

1.1. What is JUnit 5?

Unlike previous versions of JUnit, JUnit 5 is composed of several different modules from three different sub-projects.

JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

For now all test cases except one are marked as @Ignored and that requires student to open test file and remove this annotation one-by-one. I think it might be improved: with predefined test order and fail-fast enabled student will see only one failed test-result at a time (and can concentrate on working on it) but there will be no need to edit test cases files.

[mikegehard]

Ah yes...I totally agree that upgrading to JUnit 5 would be a great idea.

And now I understand you thoughts on the pre-defined test order. Yes that would be an interesting experiment to figure out if that improves student experience because they don't have to remove the @Ignore.

The TDD purist in me has a concern exposing students to the @Order annotation. That concern is that they will see that early in their careers and will then start to use it outside of Exercism. By fixing order in a test suite, when doing TDD, you can cause some subtle bugs because the test can rely on existing state.

That said, we have had some issues in the past with folks not fully reading the instructions and not removing the @Ignore annotation so they didn't implement the full solution.

For now, what if we just implemented JUnit 5 and came back to the "student experience" question. Might be something we want to talk more widely about to get more feedback.

Maybe once we get the issues area cleaned up we can start a discussion issue?

[dector]

I thought about using order in education purposes as a ladder for making steps from simpler test-cases to more difficult. But in general, we can use just fail-fast approach.

Maybe once we get the issues area cleaned up we can start a discussion issue?

Sounds good for me.

[mikegehard]

👍

[dector]

Also, as I see v3 tracks gonna dive dipper into idiomatic languages. v2 are more about idiomatic syntax.

Also there are many Kotlin testing frameworks: starting from classic JUnit-family to Spek or kotlintest that allows to write more readable / better structured tests.

[mikegehard]

Not sure I follow...

[mikegehard]

Issue #310 is an existing issue for adding stub files.

[dector]

Thank you. Will take a look.