The End of the Course

We started this course with the goal of learning how to write effective tests. As programmers, we always pay a lot of attention to writing clean and maintainable applicative code, but often we forget to apply the same principles to tests. Whether we follow the principles of TDD, BDD, or another methodology, writing clean and maintainable tests should always be our priority. It doesn’t matter if we like to write tests first, applicative code first, or some applicative code and some tests in an iterative process. What matters is that our tests are well designed, with maintainability, readability, and extensibility in mind.

In this course, we focused on Scala and some testing libraries in the Scala ecosystem. However, the principles we outlined and the suggestions we shared apply to other programming languages and libraries.

Content

First, we learned how to use ScalaTest. We went through some necessary theoretical lessons to set a common background on the syntax and the testing styles. Then we explored some advanced features, such as fixtures, testing asynchronous and eventually-consistent code, the generation of testing reports, and tagging. Along the way, we analyzed different ways to achieve the same results, using both Scala-only constructs and ScalaTest syntactic sugar. We also established a set of best practices that can guide you in the design of your tests.

Next, we moved to a controversial topic in testing: mocking. We learned when mocking is appropriate and when it’s not and that there are different types of test doubles, all with pros and cons. We looked at writing our own test doubles and how that differs from using a dedicated library. In particular, we focused on Mockito, which is only one of the mocking libraries for Scala or Java that we can import in our projects.

Remember that the future of mocking in Scala depends on how and when the mocking libraries align with Scala 3. This is especially difficult for the libraries, such as ScalaMock, that rely heavily on Scala macros. Throughout the discussion, we analyzed how to refactor our code to make it work better for mocking. As we saw, not all code is suitable for mocking, and often refactoring it to make it more mockable leads to an improvement in the quality of its design. This is especially true when it comes to mocking a Scala object.