```describe( title = "A Lucee only suite", b...
# box-products
a
Copy code
describe(
			title = "A Lucee only suite",
			body  = function(){
				it( "should only execute for Lucee", function(){
					expect( server ).toHaveKey( "Lucee" );
				} );
			},
			skip = ( !isLucee() )
		);
z
still way too much boiler plate, tests should be focussed
a
scenario / story / given / when also support it. So a test suite of :
Copy code
scenario(
  title = "Service x is available",
  body  = function(){
  ... given / when / then nested in here
})
z
public function beforeAll(){
var redis = serve*r.getDatasource("redis");*
if ( structCount(redis) eq 0 )
return false;
defineCache();
}
return false or skipAll()
a
I don't see that as much cleaner than
skip=structCount(redis) eq 0
in the scenario (or feature etc)
just my view 🙂
z
lucee has thousands of tests.... my approach is cleaner IMHO
a
There being 1000s of tests is neither here nor there
beforeAll
acts on all tests in the suite; the outermost
describe
also does. Either impacts the same number of tests. I do not see either option being cleaner than the other. The
describe
approach also has the merit of already being in place. I do think that giving special powers to a return value of
false
from
beforeAll
seems a bit magical. But not egregiously so, that said. I like the idea of having a mechanism like
skipAll
or
exitSpec
or
failAll
or
failRest
or something that one could put anywhere in the context of a spec - so within a
describe
/
it
callback etc (and indeed in
beforeAll
!) - which then does what it suggests: doesn't run the rest of the tests, marking them failed. This seems clearer in intent than
return false
being given special meaning.
👍 1
I have needed to abort all further tests in a suite if some initial state cannot be met... usually on integration tests that rely on the state of an external resource, where the state can't be entirely controlled by the tests themselves. So it's a good idea. Just... needs a thread like this to nut out how best to implement it.
Sidebar, I really with CFML could handle a mix of positional and named arguments, eg:
Copy code
describe("tests of the thing", () => {
}, skip=!isOKToRunThese())
Rather than needing to specify them all:
Copy code
describe(
    title = "tests of the thing",
    body = () => {
    },
    skip=!isOKToRunThese()
)
Or include all positional ones (incl the ones one doesn't care about):
Copy code
describe(
    "tests of the thing",
    () => {
    },
    [], // what even is this?
    false, // or this?
    !isOKToRunThese()
)
a
I just looked at the
describe
signature and there is a
focused
have never seen that before and no idea what it does!
Oh it's related to
fdescribe
Copy code
Focused Describe, only this should run
Sorry - added a sidebar to your sidebar Adam 🙂
a
"... and another thing...."
😁 1
z
skip( )
and
skipAll()
was the original idea, we have 16 and counting external services in the Lucee test suite. I have already done the hard yakka abstracting that all out into https://github.com/lucee/Lucee/blob/6.0/test/_setupTestServices.cfc rather than each test reading and checking env and sys properties
@lmajano asked me if i wanted to have a go at implementing them, i'd love to but i'm quite flat chat on trying to get the Lucee 6.0 beta out
anyone keen to have a go?
a
I think someone who is actually responsible for the design of TestBox (so Luis or Brad etc) should decide what they want before anyone starts fart-arsing around with code.
z
been there done that, hence @lmajano asking me to have a crack???
a
There's no way that ticket reaches any sort of "definition of ready". The description is completely empty. We've been discussing
skipAll
and the ticket is about
skip
. How does the skip present itself in the output (I guess same way it does now with the skip param actually)?
z
skipAll{}
has the same effect as
component skip=true {}
skip{}
has the same effect as
function(etc) skip=true {}