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

Make tests for the invoke module more stringent #56

Open
gkapfham opened this issue Aug 24, 2018 · 6 comments
Open

Make tests for the invoke module more stringent #56

gkapfham opened this issue Aug 24, 2018 · 6 comments

Comments

@gkapfham
Copy link
Collaborator

Current the tests in the test_invoke suite are achieving full statement coverage. However, the tests do not have stringent checks on the status of the function under test, like invoke.invoke_all_fragment_checks. These tests should actually inspect the results of the report that is populated after performing the check and make sure that it contains the expected results.

@gkapfham
Copy link
Collaborator Author

gkapfham commented Jul 9, 2019

Note that issue may be less of a concern once we go to a linting interface, as described in Issue #175.

@simojo
Copy link
Collaborator

simojo commented Jan 20, 2020

Think this would be a good issue for me to start on? I'm not sure if the linting interface lessened its importance, though.

@Michionlion
Copy link
Member

Michionlion commented Jan 21, 2020

I think this is definitely still something that needs to be fixed, although depending on your confidence in understanding of the system you may want to start with a simpler issue -- this one will require some knowledge of how we create a report dictionary, and what the contents of that dictionary should be for various invocations of the check functions. Note that some individual checks also may have test suites attached, and we want to try to multiplex our testing suites (have different inputs for as many situations as possible); thus, in adding to the test_invoke suite we'll want to make sure we're using different values and possibly triggering different edge cases than the individual check tests if possible.

@simojo
Copy link
Collaborator

simojo commented Jan 21, 2020

Yes, good point. I wouldn't want to make any duplicates or unnecessary tests. What issue would be a good-first-issue then?

@Michionlion
Copy link
Member

I think the best places to start, issue-wise, may be #196 or #194. I'd also recommend just browsing the code and trying to understand how things work -- if you want to join the GatorEducation slack channel that would be a good place to learn and ask questions that might not be as issue-driven. If you do that you could probably start trying to tackle this one too, with a bit of help from @gkapfham @corlettim @schultzh @alexheinle and myself.

@gkapfham
Copy link
Collaborator Author

Hi @sjones-gh, thanks for your interest in the project! Let us know if you have questions about picking an issue that you can start to work on as we are all glad to help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants