在实践中如何实现持续集成和自动化测试？

Question

I know what unit testing is, why it should be used and how to write them. However, I'm not sure do I understand the terms "automated tests" and "Continuous integration" correctly. I have some general understanding about those but would like to know how do they look in practice, for example in PHP (or at least in other languages). So:

1. Is the term "automated testing" the same as "unit testing"? Or "automated testing" should be considered as a collection of unit test classes?

2. "Continuous integration" is just a matter of organizing the work in dev team and its goal is to have a most-recent AND tested software revision at the end of each day. So, everybody should put his code into codebase frequently (for example at the end of every working day), and also, everybody should commit they unit tests into some test manager that runs all unit tests (performs automated testing). So, after automated testing (execution of all unit tests) and hot-fixing bugs at the end of day, we have a shippable software code revision.

Answer 1

Unit Testing != Automated testing

Unit testing is pretty old. It's verifying (tiny) units (methods, classes) of your code work as expected. e.g. Verifying boundary conditions, logical paths, etc. Thus unit-testing can be manual as well.. e.g. you key in some inputs and manually verify that it works.
Automated testing is tests that don't require a human to execute the tests or interpret the results. So these are tests that can be run on command and will tell you if everything works as expected or not. Automated tests could be automated unit tests or they could be system level / acceptance tests or performance tests or anything else...

CI

You're pretty close... except that it isn't at the end of the day, it's almost all the time. The main purpose of a CI build is quick feedback (Bonus: a potentially shippable revision of the software at all times) and less time integrating everyone's changes. Whenever someone makes a check-in, the CI mechanism would check out all the source, build to check for compilation errors and then most probably kick off unit tests and finally some system level tests. This way, a bad check-in / failures are detected as early as possible (and in some cases, you configure it such that the check-in never gets into version control i.e. reverted).