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 databa

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.