All of the unit tests and acceptance tests are run by the developer before any code is checked into the repository. All of the unit tests must pass and all of the acceptance tests that were passing before must also pass before code can be checked in.
If the unit tests have been designed to run quickly – under 5 minutes, then this is a good practice. The acceptance tests are an entirely different matter. The idea behind running the acceptance tests before checking in is that there is a good chance of identifying any new bugs introduced by the developer’s new changes and can be thought of as the ultimate regression test.
This argument sounds very nice in theory, but in practice what happens is that as the number and complexity of the acceptance tests grow, the longer it takes to run them. The extreme programming project that I worked on in Chicago at one point had so many acceptance tests that it was taking over an hour to run. The problem with running tests that take a long time to execute is that it severely impacts developer productivity and moves the focus from designing and writing code to testing it instead.