Re:The Difference Between Unit Testing and Integration Testing
by hammerdr on Tuesday May 31, 2011 @05:30AM
(#2601964)
A quick way to distinguish these in web apps is that integration tests typically are going to cross IO-barriers like calling a web service or accessing a database. If you're writing a layered architecture, this will be across those layers.
Unit tests should always be really, really easy to write. If they are not, then that is a 'smell' in your code that indicates one or more of the following things:
* If you cannot inject fakes of dangerous/unpredictable dependencies, you are probably creating these within the class. Pull that up! Or at least make it override-able. [1]
* Your class/function under test is doing way too much. Break out responsibilities into other methods or classes.
* Your test is too big! Think smaller. For example, if you're writing a test case for a recursive function, maybe you can start with the terminal condition instead of the whole thing together.
* You're actually writing an integration test. That's okay. Those are useful too :) They just take a bit more elbow grease.
[1] A great example of this is the DateTime object that this author mentioned. If you make heavy use of the DateTime.Now/Today in your code, you can and should make a 'freezable' wrapper class. Basically, you can freeze the clock at any time you wish. You can then thaw the clock and it goes back to using DateTime.
Unit tests should always be really, really easy to write. If they are not, then that is a 'smell' in your code that indicates one or more of the following things:
* If you cannot inject fakes of dangerous/unpredictable dependencies, you are probably creating these within the class. Pull that up! Or at least make it override-able. [1]
* Your class/function under test is doing way too much. Break out responsibilities into other methods or classes.
* Your test is too big! Think smaller. For example, if you're writing a test case for a recursive function, maybe you can start with the terminal condition instead of the whole thing together.
* You're actually writing an integration test. That's okay. Those are useful too :) They just take a bit more elbow grease.
[1] A great example of this is the DateTime object that this author mentioned. If you make heavy use of the DateTime.Now/Today in your code, you can and should make a 'freezable' wrapper class. Basically, you can freeze the clock at any time you wish. You can then thaw the clock and it goes back to using DateTime.