irods / irods_client_nfsrods

An nfs4j Virtual File System implementation supporting the iRODS Data Grid
BSD 3-Clause "New" or "Revised" License
9 stars 9 forks source link

Investigate inconsistencies in tests #187

Closed ganning127 closed 1 year ago

ganning127 commented 1 year ago

create, list, rename, copy, move, and remove file should be (to account for linux vs macOS)

# error code 1 on mac, error code 2 on linux
[ ! $status -eq 0 ]
# [[ "${output}" == *"ls: cannot access"* ]] # this line doesn't hold true on mac
[[ "${output}" == *"${FILENAME}"* ]]
[[ "${output}" == *"No such file or directory"* ]]

failing on linux, but not on macOS (on 46.main.restart branch)

ocasionally failing on macOS (on main), but can't re-produce. it's happened once or twice out of all the times I've ran these tests

trel commented 1 year ago

so we need a little switch/case statement for the two OSs that exhibit different behavior.

NFSRODS is fine, this is just capturing the correct expectations in the testing.

korydraughn commented 1 year ago

I don't think we even need to detect the difference between the OSs.

The test only needs to confirm that a non-zero error code is returned and the common part of the error message exists. Essentially, what's already reported in the BATs sample.

trel commented 1 year ago

that's fair - if we just want to assert non-zero.

korydraughn commented 1 year ago

I think this may be due to the BATS (the test framework) rather than NFSRODS. For example:

Executing the commands manually succeed too, so this makes me think we may have written a bad test.

korydraughn commented 1 year ago

This situation turned out to NOT be BATS.

This was an actual bug in the implementation where we weren't clearing some caches at the correct moments.

With the recent commits, the tests pass consistently.

trel commented 1 year ago

Wild. Thanks tests!