Surely, by the time something gets committed to master, a developer has already run all the unit tests before and fixed any errors that might've occurred with their new code.
Or not. There can be many reasons why this can happen:
- The developer doesn't have the discipline to do that
- They have forgotten
- They didn't commit everything and pushed an incomplete commit set (thanks Matthieu M.)
- They only ran some tests, but not the whole suite (thanks nhgrif)
- They tested on their branch prior to merging (thanks nhgrif * 2)
But the real point is to run the tests on a machine that is not the developer machine. One that is configured differently.
This helps catch out issues where tests and/or code depend on something specific to a developer box (configuration, data, timezone, locale, whatever).
Other good reasons for CI builds to run tests:
Testing on different platforms other than the main development platforms, which may be difficult for a developer to do. (thanks [TZHX][3])
Acceptance/Integration/End to End/Really long running tests may be run on the CI server that would not be run on a developer box usually. (thanks [Ixrec][4])
A developer may make a tiny change before pushing/committing (thinking this is a safe change and therefore not running the tests). (thanks [Ixrec][4] * 2)
The CI server configuration doesn't usually include all the developer tools and configuration and thus is closer to the production system
CI systems build the project from scratch every time, meaning builds are repeatable
A library change could cause problems downstream - a CI server can be configured to build all dependent codebases, not just the library one
) [3]: What's the point of running unit tests on a CI server? [4]: https://softwareengineering.stackexchange.com/users/161917/ixrec
