Allow Matches and ErrorMatches matches to use an already-compiled regexp.Regexp #137
Conversation
|
@frankban I've gone ahead and pushed missing tests for this functionality to maintain the 100% test coverage of |
|
I added the following tests: I added the following documentation: |
…exp.Regexp This allows users to have full control over the pattern used for matching, and all of its flags (multiline)
- qt.ErrorMatches single-line match `expectedNegateFailure` - qt.ErrorMatches multi-line match `expectedNegateFailure` - qt.ErrorMatches multi-line match `expectedCheckFailure` - qt.PanicMatches single-line match `expectedNegateFailure` - qt.PanicMatches multi-line match `expectedNegateFailure` - qt.PanicMatches multi-line match `expectedCheckFailure`
pajlada
force-pushed
the
feat/checker-accept-regexp
branch
from
6403f3a
to
b3b1f6c
Compare
…atches Documentation added both to the checker.go file and the README.md file
pajlada
force-pushed
the
feat/checker-accept-regexp
branch
from
b3b1f6c
to
08f7639
Compare
|
Released as v1.14.5 |
This allows users to have full control over the regular expression used for matching.
My use-case was matching a multiline string pattern, and the way MatchString was used in the
match-function made that infeasible.With this change, I was able to use the Matches matcher like this:
Happy to update naming of variables on request.
I left naming of parameters/arguments on purpose to keep the diff minimal, but happy to change that too.
As an alternative, if this change is not acceptable, I know I could implement my own Checker handles regular expressions like this, so no worries if this change does not fit into the project!