Hi James, Start with the basic Agile presumption about unit tests: they are very fast (you should be able to run about 100 unit tests in a second), so that you don’t mind running them with every compile, and must always run at 100% before checkin. Integration tests are pretty much anything else. They generally involve I/O, complex processes, interaction with other systems, but most importantly: they are frequently comprehensive and slow (so that you don’t want to run them every time), and most significantly, you can define them so that they don’t always have to pass.
It is this last aspect that explains the use of two separate goals. One one of integration tests is to give developers something to aim for. While unit tests are written by developers as they add features, integration tests can be designed by testers from requirements before the relevant features are ready. In this way, they can act as a measure of how much work still needs to be done. In theory, if your testers are fast enough, you could define “done” as happening when the integration tests pass at 100%. If you’re interested, I explain this in the final section of my maven video course (see my sig) Regards, Russ On Nov 13, 2013, at 10:20 AM, James Green <james.mk.gr...@gmail.com> wrote: > I love the FAQ entry that states that it is intended for running > integration tests. > > The next entry should read: What do you call an integration test? > > I've asked around and no-one comes up with a consistent answer. I guess it > depends on what is executing the integration test. In this case maven is > invoking someone after the packaging phase so should I expect to run tests > against the packaged binary artefact? Is that the purpose here? > > Thanks, > > James ----------------- Author, Getting Started with Apache Maven <http://www.packtpub.com/getting-started-with-apache-maven/video> Come read my webnovel, Take a Lemon <http://www.takealemon.com>, and listen to the Misfile radio play <http://www.fuzzyfacetheater.com/misfile/>!
