#41: Make unit tests of `update_one` and `update_all` method

[funnyVOLT]

• Covered update_one unit test

• Covered update_all unit test In the third key point, you mentioned the potential substitution of update_all with multiple instances of the update_one method. update_one method have some problems. For instance, when the first parameter of the update_one method is the path of a newly added file, it returns an error. Furthermore, the same holds true when the first parameter of the update_one method corresponds to a file that has not been updated. To leverage the update_one method in a manner similar to the update_all method, it is imperative to refine and update the update_one method accordingly.

• 41

[kirillt]

For instance, when the first parameter of the update_one method is the path of a newly added file, it returns an error. Furthermore, the same holds true when the first parameter of the update_one method corresponds to a file that has not been updated.

Interesting, thank you for this observation. Initially, the idea was that update_one must be called only on up-to-date index (when we know that exactly 1 path was updated). But it might be a good idea to allow updates on outdated index to make it more robust.

[funnyVOLT]

For instance, when the first parameter of the update_one method is the path of a newly added file, it returns an error. Furthermore, the same holds true when the first parameter of the update_one method corresponds to a file that has not been updated.

Interesting, thank you for this observation. Initially, the idea was that update_one must be called only on up-to-date index (when we know that exactly 1 path was updated). But it might be a good idea to allow updates on outdated index to make it more robust.

May I update 'update_one' method?

[kirillt]

@funnyVOLT yes, sure. Although you've already changed it to work on non-up-to-date index by ignoring the lookup error, haven't you? Any way, new ideas are welcome.

[kirillt]

@funnyVOLT good stuff, but could you also compare results in the test? Sequence of update_one calls and update_all should provide exactly the same result. Would be great to have some assertions about it.

[kirillt]

Something like this:

let mut index1 = index.clone();
index1.update_all(...);

let mut index2 = index;
for (path, id) in single_updates {
    index2.update_one(path, id);
}

assert_eq!(index1, index2);

Cherry on top would be randomly generating single_updates and doing this assertion in a loop.

[funnyVOLT]

Something like this:

let mut index1 = index.clone();
index1.update_all(...);

let mut index2 = index;
for (path, id) in single_updates {
    index2.update_one(path, id);
}

assert_eq!(index1, index2);

Cherry on top would be randomly generating single_updates and doing this assertion in a loop.

@kirillt, I already implemented similar test case in this function. https://github.com/funnyVOLT/arklib/blob/30cb80abb296d1a0b71345224545601af975d38a/src/index.rs#L1090

[kirillt]

@funnyVOLT yes, I've seen this. But this test case doesn't compare output of update_all and update_one. It only asserts on output of update_one.

[funnyVOLT]

@funnyVOLT yes, I've seen this. But this test case doesn't compare output of update_all and update_one. It only asserts on output of update_one.

@kirill Added test code comparing update_one and update_all. https://github.com/funnyVOLT/arklib/blob/a05e2d0300aef3824b4b347b443d2f60e466165c/src/index.rs#L1160

[kirillt]

Superseded by #72