This time I decided to torture myself and try learning Rust by writing integration tests. It was my first time using Rust and writing integration tests. However, @jerryhue taught me a lot about Rust, so the process wasn't as painful as I expected😅
Process
I learned that integration tests are testing whether all the smaller modules in the code work when joined together. That is why they are called "integration" tests, they primarily focus on the integration aspect of the code. 💡
In Rust, integration tests are conventionally placed on a directory named "tests", which should be inside the root directory of the project.
The first problem I encountered was accessing the code to test it.😵
In C#, I knew that if I wanted to use a package, I would need to add a reference to it (usually added through the UI of the IDE I use), and then I could bring the name into the file with another name using the using statement.
In Rust, there is a similar mechanism, however, there is a slight difference and that is in the fact that it is built-in. All integration tests found in the tests folder can access the application code to test it, if the application code is found in the lib crate. This was the main issue. Before, yassgy had all of the code placed inside the binary crate, making it inaccessible for the tests.
I created an issue to address this. JerryHue answered by making a small change so that yassgy had its application code in the library crate.🥳
After I pulled the changes, I started working on the integration tests!
Creating a simple integration test
I opened an issue to create a small integration test that would test the "normal" behaviour of yassgy, which means, no weird inputs or interactions, just normal values that yassgy should accept with no issues.
Because it was my first time implementing an integration test at all🙈🥶, I asked JerryHue for a little advice on how I should approach this.
He basically told me that integration tests should work like unit tests, but with more assertions happening across several layers, and with real components (file systems, networks, databases, etc).
For example, if there was a specific part of the code that created a file, my integration test should check that creation by opening that created file. If the opening went wrong, that means either yassgy did something wrong, or the file system failed. The second situation is not as common, but it could happen.
I mainly focused on two situations in my PR: passing a single file to yassgy through the StaticSitestruct, and passing a directory that contains several files.
For the first case, I called the StaticSite::from_file() method, to create a StaticSite value, by passing a path to a single file. After creating the value, I then called site.create(), and passed a file path to a directory that yassgy will create to place the generated HTML file.
After that, I did some assertions, just like the tests that JerryHue did for the HtmlPage structure. First, I opened the HTML file that yassgy created, and then I read its contents into a string to then assert whether it was equal to an expected string.
For the second case, I did something similar. The major difference was when opening the resultant files, since first I had to open the directory and get all the filenames available in that directory, and then I had to open each file separately.
Overall, I think the tests were easy to write, especially because JerryHue was really detailed on his explanations when we were discussing on how implement the test cases. It was nice to learn a bit of Rust.
Top comments (0)