Movatterモバイル変換


[0]ホーム

URL:


D Logo
Menu
Search

Language Reference

table of contents

Report a bug
If you spot a problem with this page, click here to create a Bugzilla issue.
Improve this page
Quickly fork, edit online, and submit a pull request for this page.Requires a signed-in GitHub account. This works well for small changes.If you'd like to make larger changes you may want to consider usinga local clone.

Unit Tests

Contents
  1. Attributed Unittests
  2. Documented Unittests
UnitTest:unittestBlockStatement

Unit tests are a builtin framework of test cases applied to a module to determine if it is working properly. A D program can be run with unit tests enabled or disabled.

Unit tests are a special function defined like:

unittest{    ...test code...}

Individual tests are specified in the unit test usingAssertExpressions. UnlikeAssertExpressions used elsewhere, the assert is not assumed to hold, and upon assert failure the program is still in a defined state.

There can be any number of unit test functions in a module, including within struct, union and class declarations. They are executed in lexical order.

Unit tests, when enabled, are run after all static initialization is complete and before themain() function is called.

For example, given a classSum that is used to add two values, a unit test can be given:

class Sum{int add(int x,int y) {return x + y; }unittest    {        Sum sum =new Sum;assert(sum.add(3,4) == 7);assert(sum.add(-2,0) == -2);    }}

When unit tests are enabled, theversion identifierunittest is predefined.

Attributed Unittests

A unittest may be attributed with any of the global function attributes. Such unittests are useful in verifying the given attribute(s) on a template function:

void myFunc(T)(T[] data){if (data.length > 2)        data[0] = data[1];}@safenothrowunittest{auto arr = [1,2,3];    myFunc(arr);assert(arr == [2,2,3]);}

This unittest verifies thatmyFunc contains only@safe,nothrow code. Although this can also be accomplished by attaching these attributes tomyFunc itself, that would preventmyFunc from being instantiated with typesT that have@system or throwing code in theiropAssign method, or other methods thatmyFunc may call. The above idiom allowsmyFunc to be instantiated with such types, yet at the same time verify that the@system and throwing behavior is not introduced by the code withinmyFunc itself.

Implementation Defined:
  1. If unit tests are not enabled, the implementation is not required to check theUnitTest for syntactic or semantic correctness. This is to reduce the compile time impact of larger unit test sections. The tokens must still be valid, and the implementation can merely count{ and} tokens to find the end of theUnitTest'sBlockStatement.
  2. The presentation of unit test results to the user.
  3. The method used to enable or disable the unit tests. Use of a compiler switch such as-unittest to enable them is suggested.
  4. The order in which modules are called to run their unit tests.
  5. Whether the program stops on the first unit test failure, or continues running the unit tests.
Best Practices:
  1. Using unit tests in conjunction with coverage testing (such as-cov) is effective.
  2. A unit test for a function should appear immediately following it.

Documented Unittests

Documented unittests allow the developer to deliver code examples to the user, while at the same time automatically verifying that the examples are valid. This avoids the frequent problem of having outdated documentation for some piece of code.

If a declaration is followed by a documented unittest, the code in the unittest will be inserted in theexample section of the declaration:

/// Math classclass Math{/// add functionstaticint add(int x,int y) {return x + y; }///unittest    {assert(add(2, 2) == 4);    }}///unittest{auto math =new Math();auto result = math.add(2, 2);}

The above will generate the following documentation:

classMath;
Math class

Example:
 math =Math; result = math.add(2, 2);

intadd(intx, inty);
add function

Example:
(add(2, 2) == 4);

A unittest which is not documented, or is marked as private will not be used to generate code samples.

There can be multiple documented unittests and they can appear in any order. They will be attached to the last non-unittest declaration:

/// add functionint add(int x,int y) {return x + y; }/// code sample generatedunittest{assert(add(1, 1) == 2);}/// code sample not generated because the unittest is privateprivateunittest{assert(add(2, 2) == 4);}unittest{/// code sample not generated because the unittest isn't documentedassert(add(3, 3) == 6);}/// code sample generated, even if it only includes comments (or is empty)unittest{/** assert(add(4, 4) == 8); */}

The above will generate the following documentation:

intadd(intx, inty);
add function

Examples:
code sample generated
(add(1, 1) == 2);


Examples:
code sample generated, even if it is empty or only includes comments


Error Handling
Garbage Collection
Copyright © 1999-2025 by theD Language Foundation | Page generated byDdoc on Fri Oct 10 22:16:58 2025

[8]ページ先頭

©2009-2025 Movatter.jp