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

Migrate data-driven tests to subtests #2098

Open
artamonovkirill opened this issue Feb 11, 2022 · 7 comments
Open

Migrate data-driven tests to subtests #2098

artamonovkirill opened this issue Feb 11, 2022 · 7 comments
Assignees
Labels
chore Some cleanup/house-keeping needs to be done here. x:status/claimed Someone is working on this issue

Comments

@artamonovkirill
Copy link

Following this Slack thread and this PR discussion

In the track, there are still some data-driven tests like:

func TestSomething(t *testing.T) {
    for _, test := range tests {
        ... some test code ...
        t.Logf("PASS: %s", test.description)
    }
}

Such tests could benefit from rewriting them with subtests:

func TestSomething(t *testing.T) {
    for _, test := range tests {
        t.Run(test.description, func(t *testing.T) {
            ... some test code ...
        }
    }
}

Pros:

  • Easier to parse test output of the test runner
  • For an IDE user, it's easy to see which test failed without the need to scroll (sometimes) lengthy output.
  • A possibility to run exactly 1 subtest

Cons:

  • test names/descriptions lowercased with underscores instead of spaces
  • no "fail fast" behaviour without checking the output value from t.Run

A (possibly incomplete) list of exercises without subtests:

@artamonovkirill
Copy link
Author

Slack thread screenshot, if it gets deleted:
Screenshot 2022-02-11 at 09 33 21

@andrerfcsantos andrerfcsantos added the chore Some cleanup/house-keeping needs to be done here. label Feb 27, 2022
@andrerfcsantos
Copy link
Member

If anyone wants to work on this issue, it is OK (and even recommended) the make PR's for individual exercises - working on this issue doesn't mean necessarily fixing all exercises yourself all at once. On the contrary, several people are more than welcome to make PR's for individual exercises where this is a problem.

We'll use this issue as a tracking issue to track all the PR's related to this.

@junedev
Copy link
Member

junedev commented Mar 15, 2022

@andrerfcsantos Did you already check whether this issue might also be related to code that produced via the generator? I have a hunch this is not just a matter of making individual PRs but this might be a generator issues that needs to be addressed.

@andrerfcsantos
Copy link
Member

@junedev Some exercises suffering from this problem do have generators, but others don't. So I don't think it's a generator specific problem, although for the exercises that do have the generator, we must adjust it. Your suggestion would be to add this capability to the generator first and then work on individual exercises? (Although exercises without a generator currently don't have this dependency)

@eklatzer
Copy link
Contributor

eklatzer commented Aug 12, 2022

Hey, to get an overview I used the following script:

#! /bin/bash

for test in ./exercises/*/*/*_test.go; do
    if [[ $test == *cases_test* ]] # ignore cases_test.go
    then
        continue
    fi
    testFileWithoutSubtest=$(grep -Li "t.Run" "${test}")
    if [ ! -z "$testFileWithoutSubtest" ]
    then
        echo "- [ ] ${testFileWithoutSubtest}"
    fi
done

Seems like the following exercises still need subtests (some might not need subtests):

Might not be needed:

  • ./exercises/practice/grade-school/grade_school_test.go (seems not to need)
  • ./exercises/practice/hello-world/hello_world_test.go (seems not to need)
  • ./exercises/practice/parallel-letter-frequency/parallel_letter_frequency_test.go (seems not to need)
  • ./exercises/practice/react/react_test.go (seems not to need)
  • ./exercises/practice/simple-linked-list/simple_linked_list_test.go (seems not to need)
  • ./exercises/practice/zebra-puzzle/zebra_puzzle_test.go (seems not to need)
  • ./exercises/practice/circular-buffer/circular_buffer_test.go (seems not to need)
  • ./exercises/practice/diffie-hellman/diffie_hellman_test.go (not sure if needed)
  • ./exercises/practice/error-handling/error_handling_test.go (seems not to need)
  • ./exercises/practice/paasio/paasio_test.go (seems not to need)
  • ./exercises/concept/animal-magic/animal_magic_test.go (seems not to need)
  • ./exercises/practice/bank-account/bank_account_test.go (seems not to need)
  • ./exercises/concept/deep-thought/deep_thought_test.go (exercise is WIP)
  • ./exercises/concept/weather-forecast/weather_forecast_test.go (not needed, as the exercise is only about comments)
  • ./exercises/practice/accumulate/accumulate_test.go (deprecated)
  • ./exercises/practice/counter/counter_test.go (deprecated)
  • ./exercises/practice/hexadecimal/hexadecimal_test.go (added usage of subtests for hexadecimal #2436-->(deprecated))
  • ./exercises/practice/binary/binary_test.go (added subtests for exercise binary #2429) (deprecated)
  • ./exercises/practice/octal/octal_test.go (deprecated)
  • ./exercises/practice/trinary/trinary_test.go (deprecated)

@eklatzer
Copy link
Contributor

@junedev or @andrerfcsantos
Could one of you check the exercises without a ✔️ and check if one of them needs usage of subtests, I am not sure about all of them, so double checking would be nice 😄 Thanks in advance
#2098 (comment)

@andrerfcsantos
Copy link
Member

Left my analysis below. This was a quick analysis of each exercise. If there's an exercise for which I wrote that we maybe could add subtests, but when tackling you conclude that is not viable, feel free to say so.

I also noticed some exercises are missing generators. Adding generators is of course optional for this task, but some refactoring into subtests could be made in a way that makes writing a future generator easier. But since you are our expert at writing generators, feel free to also add generators and we'll size the PRs accordingly ;) But it's totally ok to do some of the refactoring into subtests now and leave the generator for later, especially because I feel the generators for some exercises will require quite some work.


Seems robot_simulator_test.go might not need it but seems robot_simulator_step2_test.go and robot_simulator_step3_test.go need it, as each iteration of the loop seems to be a test?

grade_school_test.go might not need right now, but with a little refactoring maybe. For instance, it seems that TestAddMoreSameGrade and TestAddDifferentGrades are doing the same things, they take a list of students and add them. Looking at canonical-data.json, it seems these tests could be grouped by "property" and each one could be a subtest.

I think it's safe to skip this one - it only has one test and I don't think it'll ever change, so it's fine to be a regular test.

The tests here were tailor-made for the track and there's only a single test for each function, so I think we can also skip this one.

A similar situation to Grade School - there's some duplicated code between functions which could be grouped into single functions and maybe we could add a generator. Although I expect the creation of the generator and the refactoring to be significantly harder and require more thought than Grade School.

These could also be 2 separate tasks - 1 to refactor into subtests and another one to add the generator.

There seems to also be some duplicated code in this one between functions, so adding subtests at least for some tests could be a good idea. The tests seem to be a list of instructions, maybe the subtest definition itself can contain a list of string containing the operation to do at each stage.

Only has one test currently and canonical data also only specify a single test, so it's fine to leave as it is. We could add a subtest, but it seems overkill for this case.

Similar to Simple Linked List - the tests can be refactored into subtests in a similar way.

Looks like some functions are looping over tests, so maybe they are good candidates for subtests.

Also some duplication in the code that maybe can be refactored into subtests.

Some duplication in code, the function testWrite also seems to iterate over a list of tests, but not using subtests, maybe a good candidate for them?

Safe to skip this one, tests are custom for this exercise and there isn't really code duplication.

I also don't see an obvious way to refactor this into subtests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Some cleanup/house-keeping needs to be done here. x:status/claimed Someone is working on this issue
Projects
None yet
Development

No branches or pull requests

4 participants