Testing the Librarys Functionality Now that weve extracted the logic into src/lib.rs and left all the argument parsing and error handling in src/main.rs, its much easier for us to write tests for the core functionality of our code. We can call our functions directly with various arguments and check return values without having to call our binary from the command line. In this section, were going to follow the Test Driven Development (TDD) process. This is a software development technique that follows this set of steps: 1. Write a test that fails, and run it to make sure it fails for the reason you expected. 2. Write or modify just enough code to make the new test pass. 312 3. Refactor the code you just added or changed, and make sure the tests continue to pass. 4. Repeat!

This is just one of many ways to write software, but TDD can help drive the design of code. Writing the test before writing the code that makes the test pass helps to maintain high test coverage throughout the process. Were going to test drive the implementation of the part of our greprs program that will actually do the searching for the query string in the file contents and produce a list of lines that match the query. Were going to add this functionality in a function called search. Writing a Failing Test First, since we dont really need them any more, lets remove the println! statements from both src/lib.rs and src/main.rs. Then well add a test module with a test function, like we did in Chapter 11. The test function specifies the behavior wed like the search function to have: it will take a query and the text to search for the query in, and will return only the lines from the text that contain the query. Listing 12-15 shows this test:

Filename: src/lib.rs # fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> { # # } # #[cfg(test)] mod test { vec![] use super::*; #[test] fn one_result() { let query = "duct"; let contents = "\ Rust: safe, fast, productive. Pick three."; 313 assert_eq!(

["safe, fast, productive."], search(query, contents) ); } } Listing 12-15: Creating a failing test for the search function we wish we had Weve chosen to use duct as the string were looking for in this test. The text were searching in is three lines, only one of which contains duct. We assert that the value returned from the search function contains only the one line we expect. We arent able to run this test and watch it fail though, since this test doesnt even compile yet! Were going to add just enough code to get it to compile: a definition of the search function that always returns an empty vector, as shown in Listing 12-16. Once we have this, the test should compile and fail because an empty vector doesnt match a vector containing the one line safe, fast, productive.. Filename: src/lib.rs fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {