Currently besides all other activities, I am developing a habit of programming following Test Driven Development (TDD) methodology. This is a perfect time because I continue to explore Rust, a new programming language to me. Moreover, this language encourages you to cultivate this best practice by providing great documentation and well-thought ecosystem.
In our programs, we often face with exceptional situations (e.g., lack of space when you try to write a file, or absence of a resource), and we need to handle them. If you follow the TDD approach, you need to ensure that these exceptional situations are also properly covered in your tests. Id est, you have to develop tests that reproduce these exceptional situations and make sure that your code detect and handle them correctly. In this post, I want to discuss how to test exceptional situations in Rust.
Today, I want to note down my thoughts on closures. Closures are important in Rust, because they are extensively used in iterator adapters paramount in development highly performant programs. However, to my point of view this topic is not well-covered in The Book. This may be a reason why it is considered among the most difficult parts of the language. In this post, I will try to shed more light on it, hopefully making it more clear to Rust learners. Note that I am still a novice to the language, and my understanding may not be fully correct.
When you develop your first binary application using new language, the first issue that you face is how to organize your code so that you can easily extend it in the future. There is a good example in The Book on how to organize your code, parse and process command line arguments by yourself. However, in real world you would use a library to parse command line arguments, which most probably would be the clap library in case of Rust. In this article, I describe my template for creating a CLI (command line interface) application.