Closed aciccarello closed 4 years ago
Merging #1090 into master will increase coverage by
<.01%
. The diff coverage is100%
.
@@ Coverage Diff @@
## master #1090 +/- ##
==========================================
+ Coverage 65.16% 65.17% +<.01%
==========================================
Files 95 95
Lines 9036 9044 +8
Branches 2066 2066
==========================================
+ Hits 5888 5894 +6
- Misses 3148 3150 +2
Impacted Files | Coverage Δ | |
---|---|---|
src/core/lib/interfaces/bdd.ts | 100% <100%> (ø) |
:arrow_up: |
src/tunnels/BrowserStackTunnel.ts | 80.53% <0%> (-1.77%) |
:arrow_down: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update b14dbdc...5f11df3. Read the comment docs.
@jason0x43 For the case when xit
is called without a function we could mark the test as "xit: not implemented". For the other cases, I think "xdescribe" and "xit" are probably better descriptions because they could be skipped for any number of reasons.
If we want we can add the xsuite and xtest interfaces however I've never seen a tdd interface.
Btw, a quick API idea that we put into our local xit
and xdescribe
methods is to add an optional trailing 'reason' parameter to allow the recording of the skip reason.
e.g.
it('rubs the lotion on its skin', () => {
// test code
});
becomes
xit('rubs the lotion on its skin', () => {
// test code
}, 'not working properly after build machine Firefox upgrade');
We've found that more useful than a code comment because the skip reason can then appear in the test output.
@aciccarello Your thoughts on the comments sound fine to me. @RoystonS's idea of adding an optional third parameter for the x
functions also sounds pretty reasonable -- we could default to the x
skip reason, but allow the user to give something more meaningful if they wanted to.
As far as the tdd interface goes, it's just a clone of bdd with more explicit function names. (Well, it's actually the other way around.) They're intended to be functionally equivalent, so if we add something to one, we should add it to the other.
Given their similarity, though, we should probably just drop the tdd interface entirely and let users import bdd with different names if they want to.
import { describe as suite, it as test } from 'intern/core/lib/interfaces/bdd';
So maybe don't worry about tdd right now, and I'll make another issue for removing it.
After more discussion, it's probably best to move the new functionality to the tdd interface (with everything else) and just import and export it from bdd.
@jason0x43 Updated to include xsuite and xtest
test structure is taken from tdd tests.
closes #595