Kenneth Freitas

After a long journey about tests, the tools available, strategies and what to avoid, let's see good practices! How to write and maintain a good tests code base. - Clear and Concise: The test must be simple and easily to understand that the goal of the test and what it is testing. - Repeatable: I can run the same test a hundred time, and it must always return the same assertions for the same input. - Comprehensive: Must be simple to see all the things that the test uses, the AAA pattern is a good example to make clear the steps. - Independent: You must be capable of running any test individually, cannot have coupling between tests. - Validated: Well, it must validate something. - Traceable: If you are testing a method that fail, the return must be traceable to point to the original implementation, for you found the code easily. - Maintainable: Again, tests are code, so remember, if you create test for all your code, you will have two code bases at the end, so treat them equally...

There are a lot of options to organize our test, but let be aware in some details to no fell in some common traps. One test, a lot of cases: The hurts the one of the most important programming principle that is separation of responsibilities, remember one test, one case, try to create a single test that assert a lot of different case is awful. You lose the big part of the benefits of tests. Tests without assertions: Well, stranger but is very commons into a bad developer to hack the tools that verify code coverage, I will not say anything because, if a test does not have any assertion, do not test anything, so is same thing of nothing. Lack of Isolation: We see a lot of strategies to cover the real world, but if something is not properly configured, some lacks can happen and your test maybe is actually making an external request or create something at the database, this is really dangerous. Coupling between tests: Imagine that you will test a repository and the first test insert so...

 If tests are code, organizing them are extremely important. thinking about files organization, the most two common approach are: - My file, my test: The test file stays side a side from the original code, normally only differentiate by the extension. - The test project: A "folder test" that replicate the original project structure, brings the same file as their tests representations. Tests normally allow a lot of sublevels in details, like a general descriptions and tests cases, you can get this pattern to easily categorize the tests and get a better representation of what the test is, what does, and where, like: The object to test   The test case premise     The case     The case     The case   The test case premise     The case     The case When we are written the actual test, a good way to organize it is using the AAA Pattern: Arrange, Act, and Assert. This pattern is very common way to easily identify the dependenci...

When we start to write a test, we must have a well-defined goal that will be the test proposes and what we want. Normally, we think in three principal types: - Common cases: The common scenarios, for example the sum function, let's test the sum operations. - Error cases: All scenarios that give us an error, getting the sum function, if I pass a letter as parameter? - Boundary cases: This is the weird thing that none expected to happen, but surprise! Like pass a huge number to that the language cannot compute, for example. Of course, all these types depends on the level of stress that you want to bring to the tests cases and how much programming defense you applied into your code. But the reality is harder, the functions aren't only sums or something like that, we have a lot of complexity into our apps, like: external request, timers, databases, data inconsistent, etc. So to threat these scenarios, we have some tests tools to help with. - Mocks: Objects that simulate the beha...

As already said in the first part, tests are code, and be well written is essential to keep a good maintaining. And an important part of a well written test, it's your description about what the test propose. A good test descriptions and tests cases are highly util to identify bugs quickly and sometimes even to use as documentation how the code parts works and their goals. To make simpler, let's get a pseudocode of a function that return true with a number is odd. function isOdd numberToCheck:    if numberToCheck % 2 equal 0:     False   else:     True There are a lot of ways to write a good test case, but here are some common examples that are the style that I have seen with more frequency into the code bases. - Preposition style: "A number not divisible by 2 is odd" This is interesting because allow us to explain easily the business logic for what the code does, allowing us to write a lot of different cases. - Behavior style: "It should return true w...

In the software world, exits a lot of types of tests, but for a developer in your normal workday, three of them are important, unit tests, integration tests, and end-to-end tests. These types represent the famous pyramid of tests, where the base represents the number of tests and effort we must spend, and the high is how expensive is it. So analyzing this, we can see that we must spend our effort on unit tests, after integration tests, and end-to-end minimal. But what are these tests types? What are their proposals? - Unit tests: As the name suggests, this is a type of test that only will test a single unit in a single scenario. For example, if we have a function sum that receives two parameters "a" and "b", we easily can stress out this function by writing a lot of test cases by testing if is correct, if breaks, if it has good defensive programming, and so on. - Integration tests: Applications are more complicated than a simple function that sum up two numbers, p...

This is the first article about all the things that involve tests on a day-to-day for a software engineer. And let's start with the most important question: Why test? Testing application brings a lot of benefits, like catching bugs easily, after a change you only run a test to check if everything still works, without make to compile and create the whole application flow, this as said, create a faster feedback cycle to identify problems and increase the confidence to change or add code to the base. Also, improve code quality, is a code is poorly written it is really difficult to write tests to it, techniques like TDD (test driven development) are a great design tool to write a better code focused on tests, because if it's easy to test, probably the code has a good separation on concerns, size, single responsibility and so on. Well written tests, can be used to documenting the code base, if well descriptive and confident, new developers can easily found what the application does ...