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

feat: create an argument captor #375

Closed
wants to merge 2 commits into from
Closed

feat: create an argument captor #375

wants to merge 2 commits into from

Conversation

albx79
Copy link

@albx79 albx79 commented Apr 3, 2022

Fixes #366

@albx79 albx79 requested a review from asomers as a code owner April 3, 2022 13:25
@albx79
Copy link
Author

albx79 commented Apr 3, 2022

I wasn't sure where to put the new code, so I put it at the end of lib.rs. Please let me know if it should go somewhere else.

The example in the rustdoc effectively acts as a test suite (it exercises all code paths).

I'll address the build errors ASAP.

@@ -1142,6 +1142,8 @@ use std::{
atomic::{AtomicUsize, Ordering}
},
};
use std::fmt::Display;
Copy link
Owner

Choose a reason for hiding this comment

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

You can combine these use statements with the one above.

@@ -1656,3 +1659,85 @@ impl Sequence {
handle
}
}

/// Used to capture values passed to mocked methods, so you can assert on them later.
Copy link
Owner

Choose a reason for hiding this comment

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

What sorts of limitations does Captor have? Like, does it work with non-'static arguments? Does it work with static methods? Does it require the arguments to be Copy or Clone?

}

/// Create a new captor. See the documentation for [Captor](Captor)
pub fn captor<T>() -> Captor<T> {
Copy link
Owner

Choose a reason for hiding this comment

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

For constructors, I prefer Captor::new, or even Captor::default.


impl<T: Clone> Captor<T> {
/// Retrieve the list of all captured values, in chronological order
pub fn values(&self) -> Vec<T> {
Copy link
Owner

Choose a reason for hiding this comment

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

Why clone the inner vec, instead of just returning a slice?

}

/// Retrieve the last captured value, if any.
pub fn last_value(&self) -> Option<T> {
Copy link
Owner

Choose a reason for hiding this comment

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

Same here. You could eliminate the clone.

self.lock().clear()
}

/// Start capturing values. See the documentation for [Captor](Captor)
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
/// Start capturing values. See the documentation for [Captor](Captor)
/// Start capturing values. See the documentation for [`Captor`].


impl<T: Clone> Captor<T> {
/// Retrieve the list of all captured values, in chronological order
pub fn values(&self) -> Vec<T> {
Copy link
Owner

Choose a reason for hiding this comment

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

You could eliminate a clone by returning a MutexGuard instead. Maybe something like this:

Suggested change
pub fn values(&self) -> Vec<T> {
pub fn values(&self) -> impl Deref<Target = [T]> {
self.lock()

}

/// Start capturing values. See the documentation for [Captor](Captor)
pub fn capture_values(&self) -> impl Predicate<T> {
Copy link
Owner

Choose a reason for hiding this comment

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

Just in the interest of reducing typing, I suggest shortening the name:

Suggested change
pub fn capture_values(&self) -> impl Predicate<T> {
pub fn capture(&self) -> impl Predicate<T> {

impl<T: Clone> Predicate<T> for Captor<T> {
fn eval(&self, variable: &T) -> bool {
self.values.lock().unwrap().push(variable.clone());
true
Copy link
Owner

Choose a reason for hiding this comment

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

Instead of always evaluating true, would it be possible to chain Captor with another predicate?

@albx79 albx79 closed this by deleting the head repository May 5, 2023
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.

capture argument values for further assertions
2 participants