{"id":596,"date":"2017-01-20T13:31:01","date_gmt":"2017-01-20T13:31:01","guid":{"rendered":"http:\/\/dlang.org\/blog\/?p=596"},"modified":"2021-10-08T11:08:53","modified_gmt":"2021-10-08T11:08:53","slug":"testing-in-the-d-standard-library","status":"publish","type":"post","link":"https:\/\/dlang.org\/blog\/2017\/01\/20\/testing-in-the-d-standard-library\/","title":{"rendered":"Testing In The D Standard Library"},"content":{"rendered":"

Jack Stouffer is a member of the Phobos team and a contributor to dlang.org. You can check out more of his writing on his blog<\/a>.<\/em><\/p>\n

\n

\"\"In the D standard library, colloquially named Phobos<\/a>, we take a multi-pronged approach to testing and code review. Currently, there are five different services any addition has to go through:<\/p>\n

    \n
  1. The whole complier chain of tests: DMD’s and DRuntime’s test suite, and Phobos’s unit tests<\/li>\n
  2. A documentation builder<\/li>\n
  3. Coverage analysis<\/li>\n
  4. A style checker<\/li>\n
  5. And a community project builder\/test runner<\/li>\n<\/ol>\n

    Using these, we’re able to automatically catch the vast majority of common problems that we see popping up in PRs. And we make regressions much less likely using the full test suite and examining coverage reports.<\/p>\n

    Hopefully this will provide some insight into how a project like a standard library can use testing in order to increase stability. Also, it can spark some ideas on how to improve your own testing and review process.<\/p>\n

    Unit Tests<\/h2>\n

    In D, unit tests are an integrated part of the language rather than a library
    \nfeature:<\/p>\n

    size_t sum(int[] a)\r\n{\r\n    size_t result;\r\n\r\n    foreach (e; a)\r\n    {\r\n        result += e;\r\n    }\r\n\r\n    return result;\r\n}\r\n\r\nunittest\r\n{\r\n    assert(sum([1, 2, 3]) == 6);\r\n    assert(sum([0, 50, 100]) == 150);\r\n}\r\n\r\nvoid main() {}<\/pre>\n
    Save this as test.d<\/code> and run dmd -unittest -run test.d<\/strong>. Before your main<\/code> function is run, all of the unittest<\/code> blocks will be executed. If any of the asserts fail, execution is terminated and an error is printed to stderr<\/code>.<\/p>\n
    The effect of putting unit tests in the language has been enormous. One of the main ones we’ve seen is tests no longer have the “out of sight, out of mind” problem. Comprehensive tests in D projects are the rule and not the exception. Phobos dogfoods inline unittest<\/code> blocks and uses them as its complete test suite. There are no other tests for Phobos than the inline tests, meaning for a reviewer to check their changes, they can just run dmd -main -unittest -run std\/algorithm\/searching.d<\/strong> (this is just for quick and dirty tests; full tests are done via make<\/strong>).<\/p>\n
    Every PR onto Phobos runs the inline unit tests, DMD’s tests, and the DRuntime tests on the following platforms:<\/p>\n