Becoming a software developer – episode VII

Becoming a software developer – episode VII

Welcome to the seventh episode of my course “Becoming a software developer”, which is all about the importance of testing your code in general.

All of the materials including videos and sample projects can be downloaded from here.



This episode will focus on the testing per se, including the types of tests that can be written TDD, testing libraries, mocking and other interesting patterns.

  • Why & how to write the tests
  • Unit testing
  • Integration & End-to-End testing


Why & how to write the tests

If I were to think of a single reason why writing the tests is important, it would be the automation. Imagine having a complex system and no confidence whatsoever that changing your existing code or adding a new one will not break the way your application behaves. Without writing automated tests you’d have to check that your application works properly by manually following some use cases and a fixed scenario. We all know that it’s impossible to do it, and we, the human beings are more likely to forget about some feature that should be manually tested or simply don’t know about the another path that could lead to its proper usage. Thus, we need to write tests for our code that will do that for us. We will get a lot of confidence and be able to verify that the changes do not break anything in a matter of seconds.

Tests are usually divided into the 3 parts:

  • Arrange – prepare your objects, variables etc. that either should be tested or used as a method arguments.
  • Act – execute a method or a flow which behavior should be validated.
  • Assert – ensure that everything works as expected, which results in passed test.

One of the helpful techniques which is strongly related to the testing, yet is actually a part of writing a self-documented code being be covered by tests is the Test Driven Development. There is a lot of content about this technique, so I encourage you to read about it by yourself. Basically it boils down to the Red->Green->Refactor cycle in which you write a code that doesn’t work, then write a test that doesn’t pass (Red), then fix the code, ensure that test does pass (Green) and eventually improve your code (Refactor) which a full cycle that can be repeated over and over again. You can also take a look at the other interesting technique of writing the tests which sound like the stories by following the Behavior Driven Development (BDD) about which I wrote an article quite some time ago.

In order to run the tests execute the dotnet test command inside the test project directory.

Unit tests

When you want to write a test that doesn’t make use of external resources such as the database, web services etc. you should write the unit tests that operate in memory and execute very fast. If your classes depend on other classes (being passed e.g. as interfaces via constructor) you could use one of the following features: mocks, stubs or fakes to provide a basic implementation of the dependent interface which you can set up to provide a certain behavior required to properly execute a test. For example, you might be writing the unit tests for the IUserService interface that deals with the users in your application, but don’t care about the IDatabase which is being used to access the database, therefore you could create e.g. a mock and set up its behavior to return the user object for a given email address or identifier.

Integration & End-to-End testing

Integration, functional or End-to-End testing are quite similar to each other. Just think about the unit tests that would actually make use of the external resources. Connecting to the database, executing the SQL query, making the HTTP Request to some API or even simulating user’s behavior by clicking on the website or some desktop or mobile application in order to ensure that it works as expected – this are the integration tests in a nutshell. You have to bare in mind that they require much more time in order to be executed and very often a separate environment. I guess that you wouldn’t want to have some dummy data being inserted into your production database or so.



In the next episode, we’ll talk about the good patterns and practices related to the software development in general. Things like SOLID, KISS, Dependency Injection, Inversion of Control, Strategy or Proxy patterns

3 Comments Becoming a software developer – episode VII

  1. Pingback: Dew Drop - March 9, 2017 (#2437) - Morning Dew

  2. Pingback: Becoming a software developer – episode VII – Patryk Huzarski | Personal Blog

  3. Pingback: Becoming a software developer – episode XII | Piotr Gankiewicz

Leave A Comment

Your email address will not be published. Required fields are marked *