Alberto Corrales Garcia

In "Working Effectively with Legacy Code" Michael Feathers introduced a definition of legacy code as code without tests, since a code without tests is difficult to maintain, extend and evolve. It doesn't matter if you are using the latest technologies, if you don't test your code, it will hard to change without breaking anything, which will make it rigid and difficult to maintain. Remember that unit tests are the base in the testing pyramid. In order to ensure that you are covering with unit tests the most important part of our application, code coverage can be helpful to detect where you have lack of tests. Code coverage is a tool offered by products like ReSharper or the Enterprise version of Visual Studio . However, these products are not free and you might not want to pay for this essential feature. But if you are working with dotnet core, it is quite easy to get a code coverage report thanks to ReportGenerator package. In order to generate your tests, first

Introduction In a previous post we saw how you can build code snippets to write tests faster empowering your team to follow good practices.  https://www.albertocorrales.com/2018/10/writing-unit-tests-faster.html In this post, we will see how we can distribute our snippets with a Visual Studio extension, which offers different advantages, for example: You encapsulate your snippets in a VS extension, you you don't need to distribute them independently, and developers don't need to add them to VS one by one.  The extension can be updated improving he current snippets or including new snippets. You can add more functionality in your Visual Studio extension.  Creating a new Visual Studio extension First of all, if you have never developed a Visual Studio extension, you might need to install Visual Studio extension development kit. To do it, install this option in your Visual Studio Installer Create a new Visual Studio extensions project. For this example, I will

Introduction When you are writing tests, the name of the test is very important because the person who is executing the test should be able to detect what was fine or wrong at a glance. For this reason, it is a good practice to follow the convention format: TestedMethodName_InputData_ExpectedResult By using this format, we can see in a line the method to test, the input used and the result expected, so it will be easy to identify what was wrong. Another good practice is following the "Arrange", "Act", "Assert" convention ( http://wiki.c2.com/?ArrangeActAssert ), so when we are reading a test, we can identify easily each part of the test. To make more visible each part, unit test usually include one comment per each state of the test. Finally, if you are using different test categories, for example to classify unit tests and integration tests, you should use the word TestCategory("YourCategory") in your metadata definition. Using the