xUnit Glossary :

A set of terms that I learned in my GSoC about testing, xUnit and methodologies : The definitions are from the book xUnit Test Patterns (available online)

  • Basic terminology :
    • Assertion : A statement that something should be true. In xUnit-style Test Automation Frameworks, this is realized as an Assertion Method that fails when the actual outcome passed to it does not match the expected outcome.
    • Black box : A piece of software is a black box if we treat it as an opaque object whos internals cannot be seen. Tests written for this black box can only verify the externally-visible behavior and are independent of the implementation inside the system under test (SUT).
    • False negative : When a test passes even though the system under test (SUT) is not working properly, the test is said to be giving a false negative indication or a “false pass”. See false positive for a more detailed explantion of the background of this term.
    • False positive : When a test fails even though the system under test (SUT) is working properly, the test is said to be giving a false positive indication or a “false failure”.
    • A design pattern is a is a pattern that we can use to solve a particular software design problem. Most design patterns are programming language independent; the language specific ones are typically called “coding idioms”. Design patterns were first popularized by the book “Design Patterns” [GOF].
  • Smells :
    • Code smells : are the “classic” bad smells as first described by Martin Fowler in “Refactoring” [Ref]. These smells must be recognised by the test automater as they maintain test code. Code smells typically affect maintenance cost of tests but they may also be early warnings signs of behavior smells to follow.
    • Behavior smells are smells we encounter while compiling or running tests. We don’t have to be particularly observant to notice them as they will present themselves to us via compile errors or test failures.
  • Methodologies :
    • Example Driven Development EDD is a reframing of the test-driven development process to focus on the “executible specification” aspect of the tests. The act of providing examples is more intuitive to many people; it doesn’t carry the baggage of “testing” software that doesn’t yet exist.
    • Test Driven Development TDD: A development process that entails writing and automating unit tests before the development of the corresponding units is started. This ensures that the responsibilities of each software unit are well understood before they are coded. Unlike test-first development, test-driven development is typically meant to imply that the production code is made to work one test at a time (a characteristic called emergent design.)
    • Storytest Driven Development : A variation of the test-driven development process that entails writing (and usually automating) customer tests before the development of the corresponding functionality is started. This ensures that integration of the various software units verfied by the unit tests results in a usable whole.
  • Tools and strategies :
    • Continuous Integration : The agile software development practice of integrating software changes continuously. In practice, this means that developers integrate their changes every few hours to days. Continuous integration often includes the practice of an automated build that is triggered by each check in. The build process typically runs all the automated tests an may even run tests that aren’t run before check in because they take too long. The build is considered to have “failed” if any tests fail. When the build fails, teams typically consider getting the build working again to be the top priority; only code changes aimed at fixing the build are allowed until a successful build has occured.
  • Test fixture
    • Test fixture :In xUnit, a test fixture is all the things we need to have in place in order to run a test and expect a particular outcome. Some people call this the test context. Some variants of xUnit keep the concept of the test context separate from the Testcase Class that creates it; JUnit and its direct ports fall into this camp. Setting up the test fixture is the first phase of the Four-Phase Test
    • Fixture setup: Before the desired logic of the system under test (SUT) can be exercised, the preconditions of the test need to be setup. Collectively, all the objects (and their state) is called the test fixture (or test context) and the phase of the test that sets it up is called fixture setup.
    • Fixture teardown : After a test is run, the test fixture that was built by the test should be destroyed. This phase of the test is called fixture teardown.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: