TODO.txt

TODO
====

This file lists all tasks required for the next release. Items that might be
desirable for future releases may be listed at the bottom of the file.


Release
-------
-   Review test suite

-   Niggles to test/check:

    -   What happens if we try to tokenize an empty file?

    -   Do we properly handle directories whose name matches against file name
        patterns?

    -   Do we properly handle traversing towards a target that may have a
        potentially ambiguous directory name in the path? E.g., the target is
        in "tests/test_foobar/test_target.php" and the test suite also has the
        directory "tests/test_foo" (which may or may not also include a file
        "test_target.php")

    -   Do we handle traversing multiple times to a directory, file, etc. that
        had a setup error?

    -   (Directory) setup errors when there are targets

    -   Running targets that are a directory or a file that is parameterized
        with multiple argument lists, and/or in a directory hierarchy where
        one or more directories in the hierarchy are parameterized with
        multiple argument lists

-   Targets:

    -   Allow namespaces for user-provided function and class targets to be
        automatically discovered so they don't need to be specified on the
        command line. This will probably require caching the list of declared
        namespaces within a file test

-   Add support for config files(?)

-   Implement additional CLI options(?)
    -   enable/disable autoloading, and specify an autoloader file location?

-   Ensure we're UTF-8 conformant
    https://www.php.net/manual/en/migration71.windows-support.php#migration71.windows-support.long-and-utf8-path

-   Should we strip assert() calls (and potentially other debug activity) when
    building the phar? Since Dr. Strangetest requires assertions to be enabled,
    they will always be executed even though we would never expect them to
    trigger in a production release. If so, then we probably want to allow the
    phar version to be installable with Composer (a la psalm/phar, for example)

-   Dependencies:

    -   Do we handle declaring a dependency on one's self?

    -   Names given to Context::depend_on() should respect the current
        namespace scope and any 'use ...' statements. One exception is
        providing a function name from inside a class definition. In this case,
        we should automatically fallback to the current class, but prefixing
        the name with '::' should apply normal name resolution rules.

-   Test parameterization

    -   Test validation of argument lists returned by directory setup

    -   Test teardown_run for directories, including handling of multiple
        teardown_run functions

    -   Test setup_run for files, including handling of multiple setup_run
        functions

    -   Test setup_run for directories, including handing of multiple
        setup_run functions

-   Test that we don't skip any tokens when parsing files. In many cases,
    whitespace is optional, so an off-by-one error when iterating through the
    tokens means we could potentially miss a definition.

-   How do we (and should we) handle calling user functions with bad
    signatures, i.e., fixture functions or test functions with extraneous
    parameters and/or incorrect type declarations?


Future / Wishlist
-----------------
-   Support calling assert() with arbitrary exceptions in PHP >= 7? It's not
    entirely clear what this would even entail: perhaps allow treating custom
    exceptions as failures instead of errors?

-   Support "higher-level" dependencies, i.e., declaring a dependency on an
    entire class, file, or directory, all of whose tests must pass in order
    for the dependency to be satisfied. This probably means we want setup
    fixtures to be able to declare dependencies (and retrieve state), and
    teardown fixtures to be able to set state.