NorfairKing / sydtest

A modern testing framework for Haskell with good defaults and advanced testing features.
113 stars 25 forks source link

Clarification the usage of the `--filter` and `--match` flags #81

Closed eltix closed 1 month ago

eltix commented 1 month ago

I am not sure whether this is a bug or me failing to understand how those flags work. Since --filter and --match seem to be doing the exact same thing, I will use --filter in the following without loss of generality.

Let's say I have a Sydtest test suite that I run with the command nix run .#test-suite which runs 49 tests, the following being an excerpt of the console output

Data.Quantities.SimplifySpec
  simplify
    ✓ Simplifies a unit to an equivalent one                             134.12 ms
      passed for all of 100 inputs.
      Labels
        74.00% "Could not simplify"
        26.00% "Could simplify"
    ✓ Normalization is idempotent                                         43.20 ms
      passed for all of 100 inputs.
    ✓ Simplifies second * microsecond to millisecond ** 2                  0.40 ms
Data.Quantities.ExprParserSpec
  prefixParser
    ✓ parses dam as decameter                                              0.01 ms
    ✓ handles min/milliinch ambiguity                                      0.00 ms
    ✓ parses µ- as micro prefix                                            0.01 ms
    ✓ handles hecto/hr ambiguity                                           0.00 ms
  preprocessUnit
    ✓ handles prefix                                                       0.01 ms
    ✓ rejects bad unit                                                     0.01 ms
    ✓ handles base                                                         0.00 ms
  1. Now, let's say I want to run the last test only with
    nix run .#test-suite -- --filter "Data.Quantities.ExprParserSpec.preprocessUnit.handles base"

    It runs the following tests:

    
    Tests:

Data.Quantities.ConvertSpec convertBase ✓ converts to base 49.61 ms Data.Quantities.ExprParserSpec preprocessUnit ✓ handles base 49.51 ms ✓ handles prefix 49.56 ms Data.Quantities.DefinitionParserSpec makeDefinitions ✓ makes base definition 0.62 ms

Passed: 4 Failed: 0

It looks like the space character between `handles` and `base` is interpreted as an OR condition and both `Data.Quantities.ExprParserSpec.preprocessUnit.handles` and `base` are matched. 
Indeed, `nix run .#test-suite -- --filter "Data.Quantities.ExprParserSpec.preprocessUnit.handles` only matches:

Data.Quantities.ExprParserSpec preprocessUnit ✓ handles base 44.97 ms ✓ handles prefix 44.99 ms


which is the expected behavior.

So my questions are: is the behavior with space expected? If so, does that mean one must not use spaces in test descriptions?

Thank you so much for developing and maintaining this library, it is quite cool stuff.
guibou commented 1 month ago

Here is what I copied in our company channel (looks like @eltix and I are working together).

for 2. the filtering logic is implemented as follows:

    filterGuard :: DList Text -> Bool
    filterGuard dl =
      null fs
        || any (\f -> f `T.isInfixOf` T.intercalate "." (DList.toList dl)) fs

Where fs :: [Text] is the sum of all the items from the -f, or -m or --filter.

So it matchs if ANY of the filtering items (so that's a big "OR") is contained inside the concatenated tree items.

But you are right that space are understood as another item.

HOWEVER, passing without -f or -m or --filter any string does not split on " ".

So just use nix run .#simwork.jinquantities.unit -- -- 'Data.Quantities.ExprParserSpec.preprocessUnit.handles base'

@NorfairKing I'll open an MR to clarify in the --help documentation the usage of the different flag and the space

NorfairKing commented 1 month ago

@eltix I've never really paid close attention to how to deal with spaces in test descriptions.

The filter logic needs to be fixed, really, instead of "just" documented. I'm open to a proposal to fix it.

The "or" use-case of being able to specify multiple is also not so important to me because we can "just" put two tests under the same describe and "or" them that way.

P.S. If you ever run into the use-case of running partitions of tests in in separate runs on separate machines, please let me know as well.