Let’s take them one by one in detail.<\/p>\n
<\/p>\n Programmers usually write these tests. But testers should learn how to write unit tests too. You can write them after the production code (test after), or before the production code (test first). When writing them after the production code you need to take care that the production code is testable, so a phase of design and code review with testability in mind is essential.<\/p>\n An unit test is focused on a method or a class. It should be very small, a few lines of code the most. There are many ways one can make mistakes when writing unit tests, so it is not a trivial thing. Because they are small they should run in memory and a unit test should run in miliseconds. Any test that touches external dependencies (database, webservice, file system, any I\/O) is not a unit test, it is something else (integration test, integrated test, acceptance test, end-to-end test, etc).<\/p>\n The unit tests results are first of all interesting for the technical team (programmers, testers, operations, devops, etc).<\/li>\n There are many definitions of integration tests. For me an integration test is a test that checks the integration between two modules. If you have more than two modules then we have an integrated test, acceptance test or end-to-end test.<\/p>\n These tests are usually written by programmers. But often testers write them as well. The integration tests are interesting also for the technical team, as with unit tests.<\/li>\n When you want to test more than two modules integrating together, or on a whole system you have integrated tests.<\/p>\n These tests are brittle, are slow, require many resources and not recommendable. Often teams spend more time on fixing these types of tests than using them to assess the health of the system. You can read why JB Rainsberger says Integrated Tests are a Scam<\/a>. They are used too much and too often and teams who start adding automated tests consider this is the only way.<\/li>\n These are usually written by testers and they validate a certain feature of the system. Strange enough most of people refer only to Acceptance Tests when they talk about automated tests.<\/p>\n We can have acceptance tests at module level, across modules, at system level, across systems, etc. If you have an acceptance test across modules or across systems (focusing on more than two modules), then they are integrated tests. For example any test that will access a behavior through a GUI<\/a> on top of another module is an integrated test. These tests are brittle, they depend on the GUI. They are not advisable.<\/p>\n These tests are interesting first of all for the product people, for the sponsors, secondly for the testers and only thirdly for the technical team.<\/li>\n They will check if all the implementations of the same interface behave the same. In other words, they are a practical way of making sure Liskov Substitution Principle<\/a> is respected.<\/p>\n Let’s say we need two databases for a system. The user can choose which database to use, and we need to provide both of them. In order to make sure that the Data Layer (the interface) is implemented in the same way by both databases, we can write a few contract tests.<\/p>\n These tests are interesting for programmers, but also architects might use them to understand better how extensible a system is.<\/li>\n<\/ol>\n All of these tests can be used to generate executable specifications<\/a> and test reporting depending on the audience, determined by the four testing quadrants<\/a>. Also all of them can be used to identify regressions in the future.<\/p>\n If you want to learn more about the subject come to European Testing Conference 2017<\/a> and let’s chat about it. Until then feel free to ask me anything about this topic.<\/p>\n Automated tests: Why? How they help? Who needs them? There are many types of automated tests out there. Let\u2019s see the most used types of tests and understand how each… <\/p>\n","protected":false},"author":3,"featured_media":1880,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[93],"tags":[91,56,140,272,271,270,181],"yoast_head":"\n![\"Automated](\"http:\/\/blog.adrianbolboaca.ro\/wp-content\/uploads\/2017\/01\/system-under-test-1024x517.png\")
<\/a><\/p>\n\n
Unit Tests<\/h3>\n
Integration Tests<\/h3>\n
\nIf you have component teams, it is a good practice to start with the API of each module and then write the integration tests. This approach is equivalent to the test-first approach with unit tests. You can also write them after the code was written, but again you need to have in mind testability when writing the APIs of the modules and the production code of each module.
\nGood practices like Dependency Inversion<\/a>, Interface Segregation<\/a>, Single Responsibility<\/a> are important to have in mind in order to have efficient integration tests.
\nMost often I use integration tests to check how an external module (web service, database, etc) integrates with the system. They are also useful to check if connections to external systems I don’t own function well.<\/p>\nIntegrated Tests<\/h3>\n
\nThey have an apparent advantage of testing the whole system, but that is a trap. You need too many of them, usually for a medium-sized system you need too many to be feasible.<\/p>\nAcceptance Tests<\/h3>\n
Contract Tests<\/h3>\n
![](\"https:\/\/blog.adrianbolboaca.ro\/wp-content\/plugins\/dpabottomofpostpage\/apixel1x1.jpg\"){kind=tracking}
<\/a><\/table>","protected":false},"excerpt":{"rendered":"