The difference between unit and functional tests

I do it all the time.

I call everything a unit test, when it really isn't. I can't help it. I've been conditioned because I use a tool called phpUnit to run our automated testing. As a consequence, I refer to Functional tests as Unit tests. But it's important to understand the differences.

Unit tests

  • each test tests one little thing in isolation from everything else,
  • Usually a test for a small method,
  • dependencies are faked, stubbed or mocked - there is no actual database connection,
  • they run very quickly,
  • these should be the vast majority of your tests,
  • they should be built as you developer (TDD)

Functional tests

  • these are high level tests,
  • they test the integration of the system with other parts,
  • they have dependencies (ie. database, other services, filesystem, etc),
  • run much slower than unit tests,
  • these should be at a bare minimum,
  • they are best built to duplicate a test that would be run by a QA analyst
  • they should be built using something like Selenium
  • they should be run separately from the unit test suite
Mixing Unit and Functional tests in same test class is risky. It means that your setup and teardown, which might include loading of fixtures, runs with every single test, including the unit tests. If this is over enough test classes, you'll find that your test suite will quickly get to the point where no one is running the tests locally, because they take too long.
To sum up:

  1. Keep your unit and functional tests separate
  2. Never connect to the database with a unit test
  3. Always run your unit tests before a commit (they should be very fast)
  4. Build your functional tests to be front end tests, mocked with Selenium or something similar
  5. Run your functional tests as part of the QA regression suite

No comments:

Post a Comment