Skip to content

Files

Latest commit

Jul 1, 2025
3e3999a · Jul 1, 2025

History

History

test

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
Dec 30, 2024
Jul 1, 2025
May 28, 2025
May 28, 2025
May 28, 2025
Feb 2, 2023
Jan 3, 2023
Aug 22, 2024
Aug 21, 2024
Feb 18, 2025
Aug 21, 2024
Feb 5, 2025
Feb 27, 2024
Jan 26, 2024
May 28, 2025
May 23, 2025
Aug 30, 2024
May 28, 2025
Aug 21, 2024
Aug 27, 2024
Sep 26, 2024
Dec 27, 2023
Dec 4, 2024
Dec 27, 2023
Jun 28, 2024
Dec 27, 2023
Jan 3, 2023
May 28, 2025
Dec 27, 2023
May 28, 2025
Feb 21, 2025
Dec 4, 2024
Aug 22, 2024
Dec 4, 2024
Sep 23, 2024
Dec 27, 2023
Oct 22, 2024
Aug 22, 2024
Feb 18, 2025
Feb 21, 2025
Jun 28, 2024
Jun 17, 2024

README.md

Tests

Many of dartdoc's tests are large end-to-end tests which read real files in real packages, in the testing/ directory. These tests are found in test/end2end/. Smaller unit tests are found in test/ and other subdirectories.

Many of the end-to-end test cases are being rewritten as unit tests. Eventually, the content in the testing/ directory should dwindle down to very targeted tests which cannot be rewritten as unit tests.

There are some end-to-end tests which would require a serious refactoring of the implementation in order to migrate to unit tests, such as any "tool" test (testing the {@tool} directive).

Manual testing

We have not set up programmatic tests for the behavior of the front-end. Two areas of complexity which should be tested for any front-end change are:

  1. Search - this includes the search box at the top right of the desktop view, the search box in the mobile view, and the search results in the search.html page.
  2. "Base href" - This is complicated. But documentation for some code makes use of the base HTML element, and some does not, as determined by the data-using-base-href attribute on the body tag. Some URLs are constructed using this attribute, so manual testing must include a case where it is used, and a case where it is not.

For the "base-href" behavior, you can manually test with the following grinder commands:

  1. dart run grinder serve-test-package-doc - This serves the docs for the testing/test_package package at http://localhost:8002/. The "base href" settings result in a body tag like: <body data-base-href data-using-base-href="false">.

  2. dart run grinder serve-pub-package - This serves the docs for a pub package at http://localhost:9000/. Environment variables are used to pass the package name and version. For example: PACKAGE_NAME=collection PACKAGE_VERSION=1.17.0 dart run grinder serve-pub-package. The "base href" settings result in a body tag like: <body data-base-href="./" data-using-base-href="false">. Serving up a package's docs gives the opportunity for many search results.

    The trick here is to test on different pages, which should change that data-base-href attribute to different values. I think typically the value is "../" on a library page or library member page, and "../../" on a library member's member page (like a constructor of a class).

  3. flutter pub run grinder serve-flutter-docs (warning: takes a crazy long time)

    TODO(srawlins): Yikes that flutter step is too expensive. Figure out a simple grinder task for using "base href" with a simple package.