When people are talking about automated testing, unit tests get all the buzz. Alpha geeks do them all the time, Uncle Bob Martin blogs about them, Oprah invites them to her show, Mr.President.. well, you got the idea. When somebody mentions integration tests, it's like, "you should write integration tests like a good boy/girl, or you'll be punished". Those of you who are just starting automated testing probably think, "ok these integration tests must be real pain in the ass, l'm really scared". This post will ease your fears, I promise!
What's the difference, again?When we look closer at these two types of tests, we discover that there's no clear distinction between them. People tend to think that unit tests are those that test only one class. But a "unit" can sometimes consist of several closely related classes serving the same purpose. Some folks even dare to say that, regardless of what you test, unit tests are those that run fast. Ayende, for example, openly supports including interaction with a database (via NHibernate) in your unit tests. A couple of years ago you'd be banned from the community for such rebellious statements! Integration tests are meant to check how good can several units work together as a team. (There are also "functional" and "acceptance" tests that do the same, and some folks even claim to understand the difference.) People are scared to write integration tests, because they think they'll have to test the system all the way from the input screen to the database, or another screen, or a call to an external service.
Rejoice, 'cuz your fear will liberate ya!If you don't feel like writing tests for your UI, pick a testing framework that makes it easy (like this one), or start your test just one level below the UI. While the first option will keep you confident that your UI is correctly integrated with the rest of the system, the other one will help you isolate the UI from the code, improving the system design. This is the general rule: moving towards integration testing gives you more confidence, whereas unit testing helps in improving your design. As you see, you can include in your test any number of your classes, and sometimes even external services, and depending on the current trend it could be called whatever. Let's say some tests are more "unit-y" then the others, but there's no clear distinction between the two, just a continuous spectrum. For the purpose of this post, let's talk about "smaller" and "bigger" tests. Read more: Codeproject
QR:
What's the difference, again?When we look closer at these two types of tests, we discover that there's no clear distinction between them. People tend to think that unit tests are those that test only one class. But a "unit" can sometimes consist of several closely related classes serving the same purpose. Some folks even dare to say that, regardless of what you test, unit tests are those that run fast. Ayende, for example, openly supports including interaction with a database (via NHibernate) in your unit tests. A couple of years ago you'd be banned from the community for such rebellious statements! Integration tests are meant to check how good can several units work together as a team. (There are also "functional" and "acceptance" tests that do the same, and some folks even claim to understand the difference.) People are scared to write integration tests, because they think they'll have to test the system all the way from the input screen to the database, or another screen, or a call to an external service.
Rejoice, 'cuz your fear will liberate ya!If you don't feel like writing tests for your UI, pick a testing framework that makes it easy (like this one), or start your test just one level below the UI. While the first option will keep you confident that your UI is correctly integrated with the rest of the system, the other one will help you isolate the UI from the code, improving the system design. This is the general rule: moving towards integration testing gives you more confidence, whereas unit testing helps in improving your design. As you see, you can include in your test any number of your classes, and sometimes even external services, and depending on the current trend it could be called whatever. Let's say some tests are more "unit-y" then the others, but there's no clear distinction between the two, just a continuous spectrum. For the purpose of this post, let's talk about "smaller" and "bigger" tests. Read more: Codeproject
QR: