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

meta: improve library and cli tests coverage #33

Open
jeertmans opened this issue Oct 5, 2022 · 0 comments
Open

meta: improve library and cli tests coverage #33

jeertmans opened this issue Oct 5, 2022 · 0 comments
Labels
ci Continuous Integration related (GitHub actions, precommit, …) good first issue Good for newcomers hacktoberfest Issue that is created for the Hacktoberfest event

Comments

@jeertmans
Copy link
Owner

What

Currently, only a few functions are tested, which may lead to uncaught breaking changes in the future.

With the issue, I hope to motivate the need of creating more tests to extend the actual coverage.

How to

Testing library

For testing individual functions, you can create tests either inside tests modules, e.g., with mod tests (or test_my_name):

#[cfg(test)]
mod tests {
use crate::check::CheckRequest;
use crate::ServerClient;
#[tokio::test]
async fn test_server_ping() {
let client = ServerClient::from_env_or_default();
assert!(client.ping().await.is_ok());
}
#[tokio::test]
async fn test_server_check_text() {
let client = ServerClient::from_env_or_default();
let req = CheckRequest::default().with_text("je suis une poupee".to_owned());
assert!(client.check(&req).await.is_ok());
}
#[tokio::test]
async fn test_server_check_data() {
let client = ServerClient::from_env_or_default();
let req = CheckRequest::default()
.with_data_str("{\"annotation\":[{\"text\": \"je suis une poupee\"}]}")
.unwrap();
assert!(client.check(&req).await.is_ok());
}
#[tokio::test]
async fn test_server_languages() {
let client = ServerClient::from_env_or_default();
assert!(client.languages().await.is_ok());
}
}

or inside function's documentation, e.g, with examples:
/// Check if `v` is a valid port.
///
/// A valid port is either
/// - an empty string
/// - a 4 chars long string with each char in [0-9]
///
/// # Examples
///
/// ```
/// # use languagetool_rust::server::is_port;
/// assert!(is_port("8081").is_ok());
///
/// assert!(is_port("").is_ok()); // No port specified, which is accepted
///
/// assert!(is_port("abcd").is_err());
/// ```
pub fn is_port(v: &str) -> Result<()> {
if v.is_empty() || (v.len() == 4 && v.chars().all(char::is_numeric)) {
return Ok(());
}
Err(Error::InvalidValue {
body: "The value should be a 4 characters long string with digits only".to_owned(),
})
}

for testing multiple functions at the same time, i.e., the integration of multiple functions, please write tests in the tests folder.

Testing the CLI

Testing the CLI is the same as for the library, but everything is currently defined the src/bin.rs. So you should test build_cli() with different arguments and check that it correctly fails or succeed for some configurations. See clap::Command::try_get_matches_from.

@jeertmans jeertmans added good first issue Good for newcomers hacktoberfest Issue that is created for the Hacktoberfest event ci Continuous Integration related (GitHub actions, precommit, …) labels Oct 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci Continuous Integration related (GitHub actions, precommit, …) good first issue Good for newcomers hacktoberfest Issue that is created for the Hacktoberfest event
Projects
None yet
Development

No branches or pull requests

1 participant