Tag tests

In the last article, we wrote a few tests for a project to make sure that our refactoring won’t break anything. To understand the project better, we will separate the part of the domain and add a test to it. This will make the test more authentic. There is a problem with the end-to-end (e2e) tests: database under the hood. This attitude is not carefree. Firstly, those tests are rather slow.

When we talk about software design we very often use very generic and abstract words. But, how about the practice? How does it look in a real-world project? Today, you and I will start refactoring a small to-do app for better testability and maintainability. In this article, we will make the application testable. We’ll write black-box tests that will prevent from some bugs and make future refactoring easier and safer.

Testing is one of the hardest stuff in programming. Today trick will help you organize your tests and the production code. Let’s assume you have a package called orders. When you want to separate the package for tests from the production code you can create a new folder and write tests there. It will work but there’s a more clearer way - put your tests to the folder with you package but suffix the package’s name in tests with _test.

In 50′ and 60′ input data for programs from those years were written on paper tapes or punch cards. Writing code, compiling and testing loop took from a few hours to even few days. It was the beginning of programming we know it. At this time Dijkstra started his discovery. He conceived the algorithm called his name. He also noticed that programs become too complicated to be fully understood by one person.

When you have a very simple application it’s not so important to test every edge case but in a project, in the very complex domain, the priority of it will increase. The more high-quality the tests, the more high-quality the code. Mutational tests will help you with making sure you did not miss some a variant of the flow in your code. How it works Mutational testing is a test which runs other test several times but with a bit changed production code in every iteration.