-
Notifications
You must be signed in to change notification settings - Fork 0
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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
client/src/ui/task_list.rs
Outdated
} | ||
// popup rendering | ||
if let Some(popup) = self.task_popup.as_mut() { | ||
popup.render(area, buf) | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
client/src/mid.rs
Outdated
@@ -521,15 +715,16 @@ mod tests { | |||
#[test] | |||
fn test_frontend_api() { |
There was a problem hiding this comment.
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.
LCOV Report - changed_lines_coverage_report ✅All Files
Changed Files
|
LCOV Report - total_lines_coverage_report ✅All Files
Changed Files
|
commenting on unit testing standards