This is an introduction into a 4 part article on a Beginners Guide to Unit Testing. This post covers some common terminology used in Unit Testing (and Testing in general). The aim of the series is to give you a broad introduction into what it is, what the goal of unit testing is, how to do it, and some guidelines on best practice. The series is based on my experience in the field making unit testing work and ensuring it is an asset to stake holders. There is also considerable influence on my thinking from numerous blog posts and msdn magazine articles.
Here's a list of unit testing terminology (or terms that can be used in conjunction with unit testing) I use and have heard others use: (This is not a comprehensive list)
- Accessor.
See PrivateAccessor. - Assertion.
A process of ensuring a output value from a code component is the expected value it should be. Usually in the form of a statement verifying the output against a (or a list of) known good values. This verifies the statement: "If you control the input you should be able to predict the output". - Black Box Testing.
Testing a software where the tester or unit test author has no knowledge of (or access to) the code they are testing. This is not generally advisable for unit test authoring. - Boundary Values.
Describe input values to a component that are on the boundary of expected input. Ie, passing in Null or zero, negative values, or values too long or large. - Code Coverage.
A unit of measure as a percent. This measures the percentage of lines of code in an assembly how many have been touched by a unit test. - Combinatorial Test.
A technique where you specify a list of values for each input parameter and the xUnit test framework will repeatedly execute the test with all possible permutations of the input data into their respective input arguments. - Dependency.
A reference to another class, making the class under examination dependent on the referred class. Replacing dependencies with mocks or stubs is usually referred to as Mocking dependencies. - DTO.
A Data Transfer Object. An object that only includes properties designed to transfer data across communications channels. This is relevant from a testing point of view because DTO’s are seldom mocked (or stubbed) due to their simple nature. DTO’s are basically STRUCTs (no methods) except they are implemented as classes with properties to comply with coding standards and serialisation restrictions. DTO’s should only use scalar data types, or other DTO types, or interfaces. - Functional Testing.
Functional tests test a full slice through all architectural layers of a system. They verify a specific business function is performing as it was intended. These are generally not automated. - Integration Testing.
Integration tests are ideally automated and repeatable tests designed to test the interaction of two components with each other in an intended way. Integration tests are usually much larger than unit tests and take longer to run. Integration tests may or may not be automated.
See a later article for more information. - Mock.
A more complex form of dependency replacement. Property and Method behaviour can be injected by individual tests. Mocks can be handcrafted but this is generally too much work, they are usually generated by a mocking framework such as Rhino or Moq. Mocks are able to be configured for a particular test and able to report back if all the appropriate members have been accessed and were given the expected input parameters. Thereby testing the output of a class and its interaction with its dependencies. - Pairwise Testing.
A technique to combat the explosion of possible test permutations using a Combinatorial approach when a large list of values is supplied. This approach works on the assumption that most errors occur with certain combinations of input values, and careful consideration is used to choose these combinations. This approach has not gained a great deal of popularity. - PrivateAccessor (or just Accessor).
A means to set, get and invoke private/protected/internal members of a class. An Accessor usually takes the form of another class with the same name as the target class but with the suffix Accessor. One Accessor is generally coded per class. Accessors are usually not coded manually but are either generated or provided by a Unit Testing framework (such as MsTest or utilities based on reflection). - Regression
Is a term often used to describe a software component loosing functionality and breaking existing functionality by adding new features. Often used to describe "Regression Prevention Testing" or just "Regression Testing". - Stub.
The simplest form of dependency replacement. Properties simply store a value, methods have no code. The stub does not store any kind of state and nor does it offer any way of reporting if its members have been accessed by the subject under test. A stub is used if the test does not care in any way if the dependency is accessed or used by the test; it is merely “stubbing out” the production dependency class. - Subject Under Test (or SUT).
This refers to the class that is the target for a particular test. - Test Driven Development (TDD).
See a later article for more information. - Test Fixture.
A test class that resides in a test project. A test fixture contains test methods to test a production class. A test fixture targets only one production class. A production class may have many test fixtures that test it. - Unit Testing (UTs).A unit tests are tightly focused automated, repeatable, and independent tests aimed to test a very small piece of code, usually one method. The goal is to test every code path through a method.
See a later article for more information. - xUnit.xUnit refers to the various testing frameworks which were originally ported from sUnit. Tools such as jUnit, qUnit, and nUnit fall into the xUnit family.
This list will grow over time.
References:
No comments:
Post a Comment