Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generating tests for "all-your-base" exercise #473

Closed
tommyschaefer opened this issue Dec 20, 2016 · 6 comments
Closed

Generating tests for "all-your-base" exercise #473

tommyschaefer opened this issue Dec 20, 2016 · 6 comments

Comments

@tommyschaefer
Copy link
Contributor

Hi there!

I've been working on adding a test generator for the all-your-base exercise for exercism/xruby and I've run into a bit of a snag.

Everything works perfectly until I get to the last 13 (if I counted correctly) exercises that are left undefined. As far as I'm able to tell, and I certainly could be missing something, these tests aren't easy (possible?) to generate from individual tracks. Is that correct?

If so, I'm wondering if theres a way that we could add more information to the canonical-data so that different tracks could generate their tests based on the following (from the data documentation):

It's up to each track do decide:

1. What's the canonical representation of zero?
    - []?
    - [0]?

2. What representations of zero are allowed?
     - []?
     - [0]?
     - [0,0]?

3. Are leading zeroes allowed?

4. How should invalid input be handled?

Though, I'm really not to sure how that would work...

Have any other tracks successfully implemented a test generator for all-your-base? I looked through a couple of the other language repositories, but I wasn't able to find anything.

Thank you so much for your time!!

@Insti
Copy link
Contributor

Insti commented Dec 20, 2016

@Insti
Copy link
Contributor

Insti commented Dec 20, 2016

Aren't the last examples with expected: null error cases?
So you need to return/raise an appropriate error value.

Can you help us by asking a specific question about a specific case?

@dvberkel
Copy link

@stevejb71 has created a test generated and converted all-your-base with it for the xocaml track.

He probably faces similar questions, so maybe he can weigh in on the matter?

@tommyschaefer
Copy link
Contributor Author

@Insti

Aren't the last examples with expected: null error cases?

Not necessarily, for example the leading zeros test:

{
  "description"  : "leading zeros",
  "input_base"   : 7,
  "input_digits" : [0, 6, 0],
  "output_base"  : 10,
  "expected"     : null
}

This is a case where tracks can either implement leading zeros as valid or invalid.

So in the Ruby implementation, we do allow leading zeros:

def test_leading_zeros
    skip
    digits = [0, 6, 0]
    input_base = 7
    output_base = 10
    expected = [4, 2]

    ...

But the Javascript implementation does not:

xit('leading zeros', function () {
  expect(function () {
    converter.convert([0, 6, 0], 7, 10);
  }).toThrow(new Error('Input has wrong format'));
});

@dvberkel Thanks so much! I'll check out that implementation 😄

@stevejb71
Copy link
Contributor

Hi @tommyschaefer

I also allowed leading zeroes in OCaml (it felt more natural, even though it complicates the implementation).

The OCaml test generator works off a template file (one for each exercise), and substitutes in a None (OCaml equivalent of null, to indicate failure) for the null it sees in the json. Since this isn't what I wanted, I just hand-edited.

I see the test generator as a tool to help in translating exercises into OCaml, and to help updating tests when the json changes, but it will still need some human intervention for certain exercises.

@tommyschaefer
Copy link
Contributor Author

tommyschaefer commented Dec 28, 2016

Thank you so much for the help @Insti, @dvberkel, and @stevejb71!

I'm going to go ahead and close this issue since, with help from you all, I was able to get this working 😄

Thanks again everyone!!

petertseng added a commit that referenced this issue Nov 11, 2017
all-your-base 1.2.0

In #280 we made
the explicit choice to leave various cases `expected: null` where tracks
can make their own decisions (leading zeroes, the representations of
zero, whether empty sequence is acceptable as input).

There are four affected cases.

#473 results in
a discussion that some post-processing is necessary, based on the
decisions that a given track makes. One might even imagine that each
individual generator may have to reimplement base translation to arrive
at the proper answers for each case.

To ease the process of translation, instead we make some canonical
choices, explicitly show what the choices are, and offer that tracks may
make a different choice if desired.

A previous proposal did not receive support:
#468

However, this proposal differs because it does change the comments at
the top of the file.

Closes #1002 by mutual exclusion
emcoding pushed a commit that referenced this issue Nov 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants