Behavior Driven Development
Continuous integration means hooking up your test suite to your version control system so that each commit "kicks off" a run of the test suite. When test suites take a long time, this is sometimes relaxed to running the test suite at fixed intervals, such as once an hour or once a day.
Code coverage or test coverage describes the percentage of your code that is exercised by your test suite. If your test suite used half of the code in your implementation, then you would have 50% code coverage. The higher the code coverage, the less likely there are to be bugs, but even 100% code coverage does not mean no bugs exist.
A fixture is really just a fancy name for "test data".
A program which runs a test suite and usually issues a summary of what passed and what failed and other metadata about the test run.
A test which fails occasionally. This can be caused by many things, but often is due to something in the test environment changing or being corrupt. For instance, if your tests assume an empty database schema, but occasionally a test blows up and leaves behind junk in the database, some later test which assumes an empty database may fail.
Mocking is a technique where you "fake out" parts of your code to facilitate testing. For example, if you wanted to test that your code behaved correctly when the disk is full, you can "mock" the function which returns how much disk space is left to return 0, and then test that your code reacts correctly. This is a whole lot easier and faster than actually filling up the disk.
One important point that many novice testers don't quite get is that you should never mock the code you are actually testing. Instead, you mock code that it *depends* on or reacts to, such as the above example.
Smoking is slang for running a test suite, which usually involves posting the results somewhere publicly accessible in an automated way. Looking at failing test suite output is sometimes referred to as "seeing what color the smoke is".
A test suite is a collection of tests that is considered a unit. Often, small projects will only have a single test suite, but larger projects will have many. For instance, many projects will have a "core test suite" that takes a short time to run and which is used to give developers quick feedback. If the core test suite passes, then the complete test suite will be run. This makes a big difference when your core test suite takes a few minutes but your full test suite takes a few hours.
A test which is written but is known to not pass yet.
A "plan" is usually a statement about how many tests will be run.
Hey! The above document had some coding errors, which are explained below:
- Around line 3:
A non-empty Z<>