Automation tests, i.e. code that tests another piece of code. As the name suggests, these are automatic tests, thanks to them we can test our applications often and quickly - if we want to test some functionality in our application, we do not even have to run it.
If we have code, for example, for complex calculations, we can test it manually, i.e. by running the application, logging in, going to the appropriate tab where the calculations are performed, then we must fill out the form and click the appropriate button - only then will we check the result. The same procedure must be performed dozens of times, for different values. In short, it is not quite a pleasant task and it takes a lot of time. That's why automated tests were created.
Thanks to automatic tests, we can test the same process much faster. Just write a regular method to test the complex calculations you want to check. Then we fire it up and after a fraction of a second (depending on what kind of test it is), we know the result. This way we can test our calculations for different input parameters.
What are the advantages of automated testing?
#1 Testing the code more often and faster.
If automatic tests run faster than manual tests, we can test them much more often. We don't have to click through the entire application to test the appropriate function.
#2 Catching errors before implementation into production.
Thanks to good tests, we catch a lot of errors before implementation into production. Of course, we are not able to catch all errors, but certainly (conducted research shows this) the number of errors in projects where automatic tests are written is lower than in projects without such tests.
#3 Easier code refactoring.
Refactoring is a process that is difficult to carry out without testing. If we don't have tests after refactoring, we should have to click through the entire application for fear of regression errors. However, if we have tests, we can safely refactor the code and if there are any regression errors, our tests should catch them (if they are well written).
#4 Better code quality.
To be able to write automatic tests, our code must follow certain rules. Including SOLID principles and design patterns.
#5 Easier code maintenance.
Adding new functionalities to our application is easier, after each change we can check whether the code has not broken somewhere else. We follow good practices, which, by definition, should make our code easier to maintain.
#6 Code documentation.
Quite an important point that we must not forget. By using the correct naming conventions, our tests should be good documentation. Thanks to this, if a new programmer joins the team and does not understand some piece of code, he or she can just look at the well-described test methods.
What are the disadvantages of automated testing?
#1 Twice the time to write code.
It is said that the biggest disadvantage of writing automatic tests is that, at least at the beginning, the time to write our code is approximately doubled, because we have to write tests in parallel for the new method. This is not entirely true, because the time needed to write code may actually be slightly longer, but not twice as long. When developing production code, we must also develop test code (which should also be treated as production code). However, you should look at it a little differently, because the time of writing the code actually increases, but in the long run, thanks to testing, we gain this time later - during implementation. After implementation, we have about 90% fewer errors in production, and therefore in practice, thanks to testing, the time should be shorter, not longer.
#2 Focus on better code quality.
In fact, this should be an advantage (and it is!), but it depends on which way you look at it. However, following good programming principles requires appropriate knowledge, which may make the entry threshold slightly higher.
What are the types of automated tests?
#1 Unit tests.
Testing without external dependencies (such as files, database, web service, etc.). Small tests that test single units. Most of these tests are written and they are very quick.
#2 Integration tests.
Testing several units, methods with external dependencies. They are slower than unit tests.
#3 End-to-end tests.
Testing applications through the user interface, e.g. Selenium. E2E tests are the slowest.
Test writing techniques
There are 2 techniques for writing tests:
-Writing tests right after writing the code.
-Writing tests before writing code - TDD (Test Driven Development).
It is recommended to use the TDD technique, i.e. writing tests before writing the software. However, writing tests after writing code (that is, writing code and tests in parallel, but code first) is better than writing no tests at all. When writing tests after code, it's a good idea to check whether those tests check what they're supposed to. The best way to do this is to temporarily comment the production code and check whether the test shows an error (you have to remember to uncomment the code afterwards, but the tests will remind you about it).
Pyramid of tests
Applications should have the most unit tests (easy to write and fast), fewer integration tests, and the least number of e2e tests (the slowest) - this is the so-called "test pyramid".
Frameworks
To write unit and integration tests, we need an appropriate framework. C# programmers have a lot of different frameworks to choose from (programmers of other languages also have different frameworks to choose from, but I'm writing this article with C# programmers in mind), but the most popular ones are MSTest, xUnit.net, NUnit. However, I recommend using NUnit or xUnit, both have all the necessary functionalities to write good tests. MSTest is good for simple tests, but lacks the more advanced functionality that both of the others have. The NUnit and xUnit.net frameworks only differ in syntax, it doesn't matter which of these two frameworks you choose - both are good. In subsequent articles I will present my examples in NUnit.
Naming convention
The best practice for writing tests is to add two new projects to the walkthrough. One of them for unit tests and the other one for integration tests. For example, for a project with the original name "Project", our structure might look like this:
-Project
-Project.UnitTests
-Project.IntegrationTests
Typically, one test class should correspond to one class to be tested. When adding Tests to the name, for example for the Calculator class, the testing class should be called CalculatorTests.
The naming of methods varies. It is important that it is consistent throughout the entire project. The most popular convention is this:
MethodTestedName_Scenario_ExpectedBehavior
So if you want to test the Add method in the Calculator class, the testing method may have the following name:
Add_WhenCalled_ReturnSumOfArguments
Unit Testing School
If you would like to learn how to write unit tests in C#/.NET applications, consider joining the Unit Testing School - [here].
SUMMARY
Automation testing is quite a broad topic. In my opinion, it is worth familiarizing yourself with the topic of testing, because most companies where you will work will require knowledge of automatic tests, which is very good. Thanks to tests, our code is of better quality. By the way, recruiters like to ask questions about automated tests during job interviews. In the near future I will try to add a few articles about unit and integration tests on the blog.
