Open The-Compiler opened 6 years ago
To get them closer to what an user actually does, it'd even be possible to have a qute fixture or so, so you can do things like qute.run(':set foo bar').
Where we still wanted to do full tests with a real browser we could even keep the .feature
files and run the tests in-process instead of in a separate process. Assuming that some of the current issues are around connecting them via parsing logs and dumping state. Eg if we could use signals to implement the bdd steps instead maybe it would be more robust.
I've talked about this for a while, but never opened an issue for it.
In theory, I think BDD tests (the
.feature
files in Gherkin) are a good idea, and I've heard of many contributors which find them easy to write.However, in practice, they're slow and unstable - to the point that some environments are so flaky on the CI that I can't even manage to fix all the flakiness in time.
Over time, I'd like to reduce the count of end2end tests, and have more smaller unit-tests instead. I've done so for the config commands while refactoring that, and I think it's turned out nice.
To get them closer to what an user actually does, it'd even be possible to have a
qute
fixture or so, so you can do things likequte.run(':set foo bar')
.There's probably some stuff that needs to be done before this:
1638
640 (which should fix #1638)
And some refactorings which can probably nicely be combined because they make things more testable:
30
1129