Skip to content

data and constructors required by tests: Should we provide them in stubs? #466

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.

Sign up for GitHub

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

Jump to bottom
Closed
petertseng opened this issue Jan 8, 2017 · 1 comment
Closed

data and constructors required by tests: Should we provide them in stubs? #466

petertseng opened this issue Jan 8, 2017 · 1 comment
Labels
question

Comments

@petertseng
Copy link
Member

See in #464 (comment) how I argued:

  • The test is expecting the four constructors
  • If we don't provide it, the stub solution doesn't compile with the tests.
  • If we don't provide it, the student has to read the test file, find all the possible constructors, and make the data type exactly as we want it anyway.

So, I argued to provide it to the student.

We can see that this is distinct from the case where the test demands an abstract type (such as a Robot) and wishes to perform some operations on it. In this case:

  • the test doesn't care about the implementation of the type
  • the student can choose the representation
  • therefore we make a data Robot = Dummy in the stub file

In this issue I'll discuss a few exercises of the first type:

  • allergies: Allergen
  • meetup: Weekday and Schedule
  • space-age: Planet

So, should we give these three exercises the same treatment, and fully define the above-mentioned data types, with constructors?

(If doing so, we can remove the .meta/DONT-TEST-STUB file for each of these exercises)
@petertseng petertseng mentioned this issue Jan 8, 2017
Merged
@rbasso
Copy link
Contributor

rbasso commented Jan 8, 2017

I think that this is the way to go. We have to sacrifice a little flexibility in designing exercises, but we gain a more coherent user-experience and automatic testing of stubs. 👍

@sshine sshine mentioned this issue Jan 20, 2020
Merged
sshine added a commit that referenced this issue Jan 21, 2020
@sshine
Clock: Add deriving Eq to stub to make it testable (#891)
a7eed6e 
Clock is the last remaining exercise that has the .meta/DONT-TEST-STUB
file because the type in the src/Clock.hs stub is not compatible with
the test suite.

Other examples of exercises that were revised so that testing the stub
became possible are listed in #466. The difference is that those all had
`data` definitions, whereas Clock is ideally solved with a 'newtype' and
an appropriate alias.

The DONT-TEST-STUB mechanism was added by @petertseng in #464 and in
particular the commits

 - 1d91ceb (Travis code)
 - 342b932 (Clock-specific)

The change made in this commit argues that since the example solution
has `deriving Eq`, adding this to the stub *will* make the exercise a
bit easier, but it still won't give away the central piece.

The motivation behind removing DONT-TEST-STUB in Clock is that with this
single effort, we can say that all stubs can be compiled and tested. To
motivate further, I will cite @rbasso in #466:

> I think that this is the way to go. We have to sacrifice a little
> flexibility in designing exercises, but we gain a more coherent
> user-experience and automatic testing of stubs. 👍

This bumps the exercise's version from 2.4.0.9 to 2.4.0.10.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@petertseng @rbasso