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

Should we test for error messages and debug traits? #118

Closed
sffc opened this issue Jun 9, 2020 · 6 comments · Fixed by #154
Closed

Should we test for error messages and debug traits? #118

sffc opened this issue Jun 9, 2020 · 6 comments · Fixed by #154
Assignees
Labels
C-meta Component: Relating to ICU4X as a whole T-docs-tests Type: Code change outside core library
Milestone

Comments

@sffc
Copy link
Member

sffc commented Jun 9, 2020

This came up in the review for #61.

Should we write test code that exercises failure cases such that we test all Error types?

When our types implement the Debug trait, should we assert that the messages are a particular format? If not, should we at least call println! in the test file to ensure that the code is covered?

My personal preference would be to be Yes on testing all failure cases, and No on testing debug traits. I haven't formed an opinion on whether we should call println! to cause the code to be covered.

CC @zbraniecki

@sffc sffc added C-meta Component: Relating to ICU4X as a whole discuss Discuss at a future ICU4X-SC meeting T-docs-tests Type: Code change outside core library labels Jun 9, 2020
@zbraniecki
Copy link
Member

I don't have a lot of experience with consequences of either approach, so I operate on instinct here.

Using println to get coverage feels like cheating to me - you say "this line is covered, we verify that it works as intended", when it fact you don't.
I'd prefer to keep it either uncovered, or cover with a test, but it's 0.5 on apache scale. I'm ok with going in other direction :)

@sffc
Copy link
Member Author

sffc commented Jun 10, 2020

Using println to get coverage feels like cheating to me - you say "this line is covered, we verify that it works as intended", when it fact you don't.

It's marginally better than not running the code, because at least you assert that the code doesn't panic when you run that code path.

@Manishearth
Copy link
Member

Yeah typically debug impls aren't tested, given that they're mostly used while logging and debugging.

It's typical to test that an error occurs. I don't think we have to test all cases (in particular, some errors may end up being opaque objects depending on the use case) but it's worth to try and test them.

@filmil
Copy link
Contributor

filmil commented Jun 12, 2020

2 cents: once you exercise the code paths relevant in execution, incremental coverage is more useful than absolute code coverage.

Or; tl;dr: once you have ~85% test coverage, what we usually want is to have all new code exercised.

@sffc sffc self-assigned this Jun 12, 2020
@sffc sffc removed the discuss Discuss at a future ICU4X-SC meeting label Jun 12, 2020
@zbraniecki
Copy link
Member

In #112 I'm going to add documentation on what we agreed on (with examples) wrt. Errors.

@sffc sffc added this to the 2020 Q2 milestone Jun 17, 2020
zbraniecki added a commit that referenced this issue Jun 20, 2020
Fixes #112.

I shied away from extending the `errors` bit because the changes are large enough as is, and I'd prefer to keep #118 for another revision later.
@zbraniecki
Copy link
Member

I ended up not including this information in my PR for #112. We should write a new PR once that one lands.

zbraniecki added a commit that referenced this issue Jun 25, 2020
* Style Guide revision 2

Fixes #112.

I shied away from extending the `errors` bit because the changes are large enough as is, and I'd prefer to keep #118 for another revision later.

* Update style-guide.md

* Address Shane's feedback

* Reviewers feedback

* Update style-guide.md

* Update style-guide.md
@sffc sffc closed this as completed in #154 Jun 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-meta Component: Relating to ICU4X as a whole T-docs-tests Type: Code change outside core library
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants