Java: rna-transcription: make a lot of noise about deleting @Ignores

Created on 17 Apr 2017  路  19Comments  路  Source: exercism/java

I have not encountered at least two solutions that pass the first test case swimmingly, but clearly wouldn't pass the _whole_ suite:

This should be _very_ rare.

I'm taking this as a sign we're not making enough noise about deleting @Ignores.

Please update rna-transcription so that it is hard to miss the fact that once the first test case succeeds the practitioner is reminded to delete the next @Ignore.

Options (include as many as you think would be sufficient):

  • include a HINT.md
  • put comments in the test suite.
  • add some console output that prints after the first test succeeds.
  • other?
code documentation

All 19 comments

We could adopt the xcsharp-style hints in @Ignore annotations:

@Ignore takes an optional default parameter if you want to record why a test is being ignored

I'm not sure that's enough by itself, but it can't hurt!

@jtigger what is the use of the@Ignore tags ? Why do we want to ignore the test cases ?

Great question @ajayboseac. The historical discussion / policy is #101. tl;dr 鈥斅爐o make it crystal clear what failing test should be addressed at any given moment.

Thanks to @FridaTveit, we've now added hints to the ignore statements in rna-transcription to prompt users to un-ignore noninitial tests. What else should we, or do we need to, do? My current thoughts are as follows:

  • [x] add the same hints to _every_ test suite ignore statement, which I believe is how e.g. xcsharp operates;
  • [x] add explicit guidance via the HINTS.md file to the _first_ exercise that contains ignored tests. This might be best placed in the new exercise that's going to replace the current (overcomplicated) hello-world.
  • [x] capture the decisions we make in a policy, somewhere. (ref. https://github.com/exercism/xjava/issues/425)

I think that sounds like a good plan :)

Perfect!

For adding the Ignore hints to every test suite, should we make "good first patch" issues for that or should we just do it?

At the risk of sounding like a pedantic bureaucrat 馃榿 ... we currently have 11 "good first patch" issues and the policy says keep logging until we get to 20.

_That said,_ this is _your_ hobby-time... if you'd get a kick out of making sure this bit is completed, I think you should do whatever you'd like. :)

One thing to keep in mind is that, at some point, you're going to want to move on from being an Exercism maintainer1... one of the things I hope we can start doing is bringing in a few more volunteers to level-up as maintainers: this would make a decision to step away as a maintainer a guilt-free one and help keep the track going healthy. This is one of the main motivations for having a healthy "good first patch" backlog.

/long-winded-explanation


1 don't get me wrong: you're welcome here for as long as you want to stay!!! This notion of preparing for one's eventual departure by helping mentor someone into their position is our hope in making Exercism sustainable.

Okay, sounds good :) Yes, I agree that having many "good first patch" issues is important. That definitely makes it easier to contribute, and I've missed that on other projects I've tried to contibute to :)

Thanks for doing this legwork, @FridaTveit! It's very neighborly! :)

I am a new(ish) contributor. Am I limited to just fixing one of the issues?

No, you can fix as many as you like, just like you have been doing :) Thanks! :)

@FridaTveit I moved over to the ones that were not marked as "good first patch" so that I would not take too many of them from other new contributors. I see that you are working on that list as well. Would you like to divide it somehow?

@morrme That's fine :) I have a few in review but apart from that you can do whichever ones you want :)

Thank you @morrme, @mraediaz and @Smarticles101 for doing so many of these issues! :) 馃憤

@FridaTveit My pleasure!

@exercism/java do you think we've done everything we need for this now?

I have an idea. This should probably be discussed somewhere else, but what if the user was somehow warned about this by the cli? I think it would be harder to miss that way.

I think we're good to close out this issue.

@Smarticles101 Regarding CLI warnings; since the CLI is shared across tracks, I think it would be difficult to build in a warning mechanism that accommodates all the different test suites... if you think it's worth pursuing, I'd ask in https://github.com/exercism/cli to gauge feasibility!

Was this page helpful?
0 / 5 - 0 ratings