title: With Continuous Integration, why are tests run after committing instead of before?
body: <p>While I only have a github repository that I'm pushing to (alone), I often forget to run tests, or forget to commit all relevant files, or rely on objects residing on my local machine. These result in build breaks, but they are only detected by Travis-CI <em>after</em> the erroneous commit. I know TeamCity has a pre-commit testing facility (which relies on the IDE in use), but my question is with regards to the current use of continuous integration as opposed to any one implementation. My question is</p>
  
  <blockquote>
    <p>Why aren't changes tested on a clean build machine - such as those which Travis-CI uses for post-commit tesing - <em>before</em> those changes are committed?</p>
  </blockquote>
  
  <p>Such a process would mean that there would never be build breaks, meaning that a fresh environment could pull any commit from the repository and be sure of its success; as such, I don't understand why CI isn't implemented using post-commit testing.</p>