http://coldfusion.com logo
Join Slack
Powered by
```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 {}
2 Views
Open in Slack
PreviousNext
Powered by