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

Added unit tests and Github work flows to run tests and lints #10

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Mart-Bogdan
Copy link
Contributor

Lints would post all clippy warnings as annotation to pool request

@Mart-Bogdan
Copy link
Contributor Author

By the way. It should add tests count as comment to PR, like here: Mart-Bogdan#3 (comment)

I guess it is because it is not merged yet. Or because I am not a maintainer.

image

@Mart-Bogdan
Copy link
Contributor Author

By the way. It should add tests count as comment to PR
I guess it is because it is not merged yet. Or because I am not a maintainer.

Oh. That's unfortuante:

Publish Unit Tests Results
This action is running on a pull_request event for a fork repository. It cannot do anything useful like creating check runs or pull request comments. To run the action on fork repository pull requests, see https://github.com/EnricoMi/publish-unit-test-result-action/blob/v1.20/README.md#support-fork-repositories-and-dependabot-branches

.github/workflows/check-and-lint.yaml Outdated Show resolved Hide resolved
.github/workflows/test.yaml Outdated Show resolved Hide resolved
@Mart-Bogdan
Copy link
Contributor Author

Hi, @scullionw.
I've addressed commets, and removed dead code in actions.

Would there be other comments regarding tests?

Sorry for slow reaction time. I have issues with internet and electricity, and also some chores.

@Mart-Bogdan
Copy link
Contributor Author

I actually don't like to put actual files into repo, but I wasn't able to come with anything more clever.

Perhaps generating them as random files with predefined seed, hm.

Random files are mostly needed to work with compressed files.

@Mart-Bogdan
Copy link
Contributor Author

Hello, @scullionw. Happy holidays. Happy new year.

So what about this PR?)

Copy link
Owner

@scullionw scullionw left a comment

Choose a reason for hiding this comment

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

cool, thanks! lgtm once we address a few things

Cargo.toml Outdated Show resolved Hide resolved
@@ -0,0 +1,225 @@
//! Be aware that tests are run in parallel. For this reason we must be sure to use
Copy link
Owner

Choose a reason for hiding this comment

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

since we are testing the public api, can we move the tests outside src/ to be an integration test? ie tests/pathlength.rs tests/sizes.rs etc?

see https://doc.rust-lang.org/book/ch11-03-test-organization.html#integration-tests

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Need to take look at your link. And about pros/cons

For example in branch for windows, i also used private function call in tests: ffi::set_file_compression(file.path(), compress)?;

https://github.com/Mart-Bogdan/dirstat-rs/blob/max-path/src/ffi.rs#L126-L169

https://github.com/Mart-Bogdan/dirstat-rs/blob/max-path/src/tests.rs#L248

But generally, looks like you are correct. This are actually integration tests. And they interract with external world.

So looks good. Shall try doing it.

Shall test-data dir go under tests dir as well?

src/tests.rs Outdated

use crate::{DiskItem, FileInfo};
// warn: don't remove `as &str` after macro invocation.
// It breaks type checker in Intellij Rust IDE
Copy link
Owner

Choose a reason for hiding this comment

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

i'd prefer not adding IDE specific notes to the source

Copy link
Contributor Author

Choose a reason for hiding this comment

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

well. Perhaps this one is not needed. I think as &str thing is already fixed upstream in const_format crate. I shall remove this

99999999/999999/99999999/99999999999/99999999/999999999/9999999999/";

const PATH_1_FULL: &str = concatcp!(TEST_DATA_DIR, LONG_PATH_DIR, PATH_1) as &str;
//noinspection SpellCheckingInspection
Copy link
Owner

Choose a reason for hiding this comment

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

same, I think you can disable spellcheck in your idea instead

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You aren't using spellchecker plugin in vscode? Or whichever IDE you are using.

I think disabling spellchecker altogether is harmful.

It's useful in other places. And I sometimes have problems with spelling :-(

image

I don't think it's such a big deal, having this comment. We can add second one for VSCode spell checker as well :-)

src/tests.rs Outdated
let result = FileInfo::from_path(test_path, true);

// Then
if let Result::Ok(FileInfo::Directory { volume_id }) = result {
Copy link
Owner

Choose a reason for hiding this comment

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

this is equivalent to `expect("Can not get file info)",

also "Ok" is already in scope, no need for "Result" :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, you are right about Result.

About expect, just tried it. Don't work :-( it only covers Ok but don't allow to match Directory

the error is:

  --> src/tests.rs:63:9
   |
63 |     let FileInfo::Directory { volume_id } = result.expect("Can not get file info");
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ pattern `File { .. }` not covered
   |
   = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant

So anyway if let would be needed.

fn test_file_size_8KiB() {
const DIR: &str = concatcp!(TEST_DATA_DIR, "test_file_size/") as &str;
// do not rename it into `_` it would cause immediate destrucion after creation
let _guard = CleanUpGuard { path: DIR };
Copy link
Owner

Choose a reason for hiding this comment

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

this is an anti-pattern IMO. if we want to rely on drop to cleanup, we should need to use the type itself. (like create_dir taking a &GuardedPath as argument or something). easy to forget otherwise!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've eused pattern mentioned here: https://stackoverflow.com/questions/38253321/what-is-a-good-way-of-cleaning-up-after-a-unit-test-in-rust

Unfortunately I do not know better way of doing something after code is executed. Regardles if panic was raised.

Somebody are proposing setting panic hook, but that looks like dirty hack.

std::panic::set_hook(Box::new(|_| {
    cleanup();

What do you mean create_dir should take Guard as argument? Won't this cause it to clean-up straight after function call?

But ok. I can think on it after other items are resolved. Perhaps you would be able to come with something better for clean-up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll move all the code into integration tests first, I think.

@scullionw
Copy link
Owner

do all tests pass without the other PR? if not lets mark them as #[should_panic], and then remove them in the other PR, so that each PR by itself is mergeable

@Mart-Bogdan
Copy link
Contributor Author

do all tests pass without the other PR? if not lets mark them as #[should_panic], and then remove them in the other PR, so that each PR by itself is mergeable

I did not include tests that won't work without other PR. Besides, they won't compile. They are still in separate branch.

@Mart-Bogdan
Copy link
Contributor Author

Ah. shuch tests currently are marked as #[cfg(not(windows))] hmm.

@Mart-Bogdan
Copy link
Contributor Author

Hello, @scullionw, regarding integration tests.

I'm thinking. This crate exports library as well as executable. Is it required, and do we need to keep backward compatibility for lib?

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.

2 participants