search

MithrilJS / ospec

Noiseless testing framework
MIT License
48 stars 13 forks source link

Revamp the done parser with compose-regexp #16

Closed pygy closed 4 years ago

pygy commented 4 years ago

Follow up to #15 Rewrite the done argument finder from scratch, using compose-regexp.

I'm introducing ospec@4.0.1 as a dev dependency for testing the parser.

I'm in the process of porting the test suite and adding e2e tests for the CLI using the same approach: use a known good version as a harness for running the tests of the git HEAD.

This would let one b0rk the lib without also breaking the test suite completely.

dead-claudia commented 4 years ago

I don't see an issue with borking the lib itself locally during development over a bad regexp - we have automated tests to catch that here. Not convinced the risk is high enough to actually matter much as long as the relevant tests are being run in CI (where if it's borked, we'll know).

We do have issues of relying on the framework when we shouldn't in the tests, but that's something we can punt until later and resolve later. (To be honest, we could just write a stupid simple promise-driven TAP generator that logs errors to the console, one we could hand-test.)

pygy commented 4 years ago

It's not just a about a bad regexp.

I'm in the process of writing e2e tests and, more generally, it's good to know you don't mess up your testing harness while modifying your lib.

So I'm splitting up the test harness scoped as

o = require("ospec")

from the library

lib = require "../ospec.js"; oo = lib.new()

The result is a robust test suite (see #17 for WIP, it must be rebased to cleanup the history).

dead-claudia commented 4 years ago

Oh, okay, I understand now. I'll clear it then.

Edit: spelling

pygy commented 4 years ago

re. circularity, after investigation, there are scenarios where that can occur with devDependencies.

I don't think that glob has any (transitive) git-based dep, so we're not concerned, but it must be kept in mind...