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

Zon dev #109

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft

Zon dev #109

wants to merge 5 commits into from

Conversation

knoxy5467
Copy link
Owner

commenting on unit testing standards

Copy link
Owner Author

@knoxy5467 knoxy5467 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some comments on unit testing

}
// popup rendering
if let Some(popup) = self.task_popup.as_mut() {
popup.render(area, buf)
}
}
}
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add unit tests to each of these files for the popups, probably to be done by @wylyK or @squeakyu

@@ -521,15 +715,16 @@ mod tests {
#[test]
fn test_frontend_api() {
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would split this test into smaller tests. Each test should ideally be testing a single element or as few elemets as possible. that way when a test is failing you can pinpoint exactly what component is failing.

Additionally the tests should outline what conditions the test are running under and what the expected outcome is.

An example would be something like a simple TwoSum(int, int) function could be tested with 2 unit tests.

1, two_sum_suceeds_with_2_ints(): this test would test that this method would suceed and sum the two integers together when two integers are passed in.

2, two_sum_fails_with_string_input(): just the opposite of the previous example, we expect two_sum to fail if it is passed a string so we should make sure it does just that.

we split this test into two different tests so that when we run the test suite when one of them fails we know which one fails and can look at that part of the logic.

additionally unit tests should try to have a literal input, with a generated output compared against a literal expected outcome.

designing and implementing tests like this is much faster than trying to make a single monolithic test that tests everything because we have to troubleshoot less, the tests are smaller, and they test only what we need it to. having the literal inputs and literal expected outputs compared against a generated output allows for regression tests as well integrated inside of the unit tests.

So ideally I would split this test_frontend_api() into a test for each part of the API, firstly I would test the expected successful behaviors first, then in order to get more coverage I would move to testing expected failures.

As a general rule; complete unit testing would be that every function needs a minimum of 2 tests, one for expected success and one for expected fails. each if statement also needs 2 tests, one for each branch. loops need 3 test, 1 for a base case, 1 for a expected entry run and exit, and another if there is any circumstance where the loop would terminate early or throw and error.

Copy link

github-actions bot commented May 8, 2024

LCOV Report - changed_lines_coverage_report ✅

All Files

  • Lines: 3626/3942 (92.0%) ✅ (Minimum coverage is 0%)
  • Functions: 309/366 (84.4%)
  • Branches: N/A

Changed Files

  • Lines: 3532/3837 (92.1%) ✅ (Minimum coverage is 90%)
  • Functions: 295/350 (84.3%)
  • Branches: N/A
File Lines Functions Branches
main.rs 6/7 (85.7%) 2/3 (66.7%) N/A
mid.rs 1122/1216 (92.3%) 86/105 (81.9%) N/A
ui.rs 506/549 (92.2%) 17/24 (70.8%) N/A
task_list.rs 167/183 (91.3%) 18/18 (100.0%) N/A
task_popup.rs 119/125 (95.2%) 6/7 (85.7%) N/A
backend.rs 47/49 (95.9%) 21/23 (91.3%) N/A
lib.rs 49/50 (98.0%) 15/16 (93.8%) N/A
api.rs 714/805 (88.7%) 64/87 (73.6%) N/A
task.rs 499/505 (98.8%) 23/23 (100.0%) N/A
task_bool_property.rs 18/18 (100.0%) 5/5 (100.0%) N/A
task_date_property.rs 18/18 (100.0%) 5/5 (100.0%) N/A
task_num_property.rs 187/189 (98.9%) 12/12 (100.0%) N/A
task_string_property.rs 18/18 (100.0%) 5/5 (100.0%) N/A
main.rs 62/105 (59.0%) 16/17 (94.1%) N/A

Copy link

github-actions bot commented May 8, 2024

LCOV Report - total_lines_coverage_report ✅

All Files

  • Lines: 3626/3942 (92.0%) ✅ (Minimum coverage is 90%)
  • Functions: 309/366 (84.4%)
  • Branches: N/A

Changed Files

  • Lines: 3532/3837 (92.1%) ✅ (Minimum coverage is 0%)
  • Functions: 295/350 (84.3%)
  • Branches: N/A
File Lines Functions Branches
main.rs 6/7 (85.7%) 2/3 (66.7%) N/A
mid.rs 1122/1216 (92.3%) 86/105 (81.9%) N/A
ui.rs 506/549 (92.2%) 17/24 (70.8%) N/A
task_list.rs 167/183 (91.3%) 18/18 (100.0%) N/A
task_popup.rs 119/125 (95.2%) 6/7 (85.7%) N/A
backend.rs 47/49 (95.9%) 21/23 (91.3%) N/A
lib.rs 49/50 (98.0%) 15/16 (93.8%) N/A
api.rs 714/805 (88.7%) 64/87 (73.6%) N/A
task.rs 499/505 (98.8%) 23/23 (100.0%) N/A
task_bool_property.rs 18/18 (100.0%) 5/5 (100.0%) N/A
task_date_property.rs 18/18 (100.0%) 5/5 (100.0%) N/A
task_num_property.rs 187/189 (98.9%) 12/12 (100.0%) N/A
task_string_property.rs 18/18 (100.0%) 5/5 (100.0%) N/A
main.rs 62/105 (59.0%) 16/17 (94.1%) N/A

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

Successfully merging this pull request may close these issues.

None yet

2 participants