Skip to content

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.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

}

#[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.

@github-actions
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

@github-actions
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.

3 participants