In the Acronym exercise all of the tests have the @Ignore annotation which prevents them from being run by simply running test.
In order to fix that I have submitted this PR: fix: removed the @Ignore from the Tests by DerSimeon · Pull Request #668 · exercism/kotlin · GitHub
I would appreciate some feedback and if possible I would appreciate if the PR was reopened.
Suppose a student downloads the exercise, to work on their local machine.
The very first test does not have @Ignore. Therefore the first test is run.
After a student has made the first test pass, they can progressively remove @Ignore to enable more tests.
The online test runner removes all @Ignore and runs all tests. It has
find $2/src/test/kotlin -type f -name '*Test.kt' -exec sed -i "s/@Ignore(.*)//g;s/@Ignore//g;" {} \; # for JUnit 4
find $2/src/test/kotlin -type f -name '*Test.kt' -exec sed -i "s/@Disabled(.*)//g;s/@Disabled//g;" {} \; # for JUnit 5
This a common approach that most tracks use.
The default behaviour of testing in e.g Intellij is to re-run failed tests.
Its counter-intuitive to expect the student to modify the provided Test file to enable more tests.
It increases the complexity with no real benefit.
And even if you decide that it should stay like this (which I as a Student and a Mentor for others would disagree with) it should be applied to all practices to make it consistent.
My current procedure is: download exercise, remove all @Ignores and then start the exercise.
Especially the easier exercises are done fairly quickly, having to remove the @Ignore manually slows the student down (even if its by a little bit)
Agree exercises should be consistent.
But TDD - coding against one failing test error at a time - is at the heart of exercism works and has been for a decade. While I agree it is counterintuitive if you’re not used to it, I think it’s incredibly valuable for students not being hit with dozens of test failures, and for learning to solve problems step by step.
Couple of line comments:
The default behaviour of testing in e.g Intellij is to re-run failed tests.
I’m not sure what this means btw in terms of how it applies here.
having to remove the @Ignore manually slows the student down (even if its by a little bit)
I see this a feature not a bug. We’re not trying to get a student to pass an exercise in full as quickly as possible. We’re trying to reenforce breaking larger problems down into smaller segments and then solving them piece by piece.
Looking at it from a TDD POV I see your point & I agree.
Maybe instead of removing @Ignore I could propose a few PRs to add @Ignore to the exercises where its missing?
That would be awesome 
Also, I think the docs could be improved. This feels like it’s at the heart of the problem.
Compare Testing on the Kotlin track | Exercism's Docs to Testing on the Ruby track | Exercism's Docs, which does a good job of explaining this.
I will try to tackle both the consistency and the Docs.
If possible, keep this post open so I can post the PRs which would need to be reopened by one of you guys
@iHiD What do you think about this one : feat: rewrote Kotlin Testing Docs by DerSimeon · Pull Request #669 · exercism/kotlin · GitHub
Yep - looks great. Thanks for being so proactive. I’ve added a couple of comments.
Be aware that Concept Exercises don’t use Ignores because they’re actively task based. Kotlin doesn’t have a syllabus so this doesn’t largely matter, but it’s best not to touch those two exercises.
I’ll let the Kotlin maintainers and docs team take the reviewing/merging reins from here!
Thanks again
Glad I can help!
I have implemented your suggestions, the workflows need to be re-approved.
Later today I will make a few PRs to add the @Ignore to the exercises that currently don’t have it.
I will probably just dump them all in here so you or someone else can take a look and re-open them
On that note, one small question @iHiD:
Would you prefer one PR for each Exercise or one big PR for EVERY exercise?
The general rule is to do one PR per exercise. Review and potential rollbck is easier that way.
However, if you need to do over 10 of them, you might want to group them into small batches of 3 or 4 at a go. I’d check with the Kotlin maintainers to see what they’d prefer in this scenario.
Are you able to tell me who that is? or maybe give them a ping in this thread so I can get their opinion before starting?
Apologies!!
The maintainer for Kotlin is pretty busy, but will get back to you as soon as they can.
@SleeplessByte – any preference on how to group these changes? 
Tag me in the PRs and I’ll take care of them 
.
A (new) post with all the link backs here would also be appreciated.
I will make them in individual PRs to make it easier to rollback
Yeah this is usually preferred, and if you sign up for hacktoberfest I am happy to mark them as hacktoberfest PRs ;)
@SleeplessByte Hey, I would really appreciate it if you could mark them as hacktoberfest PRs.
Here is the first batch of changes:
Please approve the workflows here:
And please re-open these Pull-Requests here: