Ticket please!!

Will do. I'll get it in tomorrow... just in the process of hitting the hay right now

I am hoping this is a straight forward question I am trying to use getMockBox().querySim to mock a call to cfschedule I initially tried

existingSchedules = getMockBox().querySim(......);
service.$("existingSchedules", existingSchedules);

in my service

existingSchedules

is a local function variable

schedule action="list" result="existingSchedules";

this doesn't appear to work if I refactor my code and wrap the cfschedule in a getter I can use

service.$(method="getExistingSchedules", returns=existingSchedules);

and that works fine but I am not really keen on refactoring it that way am I missing something? the documentation implies that you can

This is a great way to simulate cfquery calls, cfdirectory or any other cf tag that returns a query.

but doesn't really explain how

Curious what folks are using for end to end testing for their web apps. Currently, using TestComplete, and it's not the most favorable experience amongst our team. It's very GUI forward, and we'd prefer something we can script tests with. I've been given the opportunity to look into a different product for consideration and have been looking at Cypress and TestCafe. Leaning towards Cypress at the moment, as the docs are pretty solid and the describe/it syntax would be familiar to the team, as I'm also pushing TestBox on them (but not a dealbreaker).

I have a coldbox handler which does some action based on the value of some coldbox flash variables. How can I mock some values in an integration test for this flash variables?

You have access to

variables.mockFlash

in your test.

You can set the values there. It will get reset when calling

setup()

.

Hi folks, TestBox development is scheduled for me to start pretty soon. So if you have suggestions, improvements, bug fixes etc, please create issues now. I am also considering adding cucumber like support. Something similar to these projects: • https://github.com/abramadams/cucumber-cf • https://github.com/Ortus-Solutions/ColdCukes Would this be of interest?

Full disclosure: I've only looked superficially.

"^I pay for the item$": function(){
    $world.result = request.registerService.makeTransaction(
        $world.price,
        $world.money
    );
},

VS:

it("pays for the item" => () {
    $world.result = request.registerService.makeTransaction(
        $world.price,
        $world.money
    )
}

Why bother? Are there ppl raising tickets saying "I don't like jasmine-style BDD testing, I can only possibly work with a cucumber DSL"? If not... it's not a good use of your time. BTW, @abram what's with the PHP variable name?

I'd rather you fix all the bugs you've already got, and work on performance than "we also provide this DSL" to an audience that largely won't care.

Bear in mind that even if you like tinkering about with DSLs and this sounds a fun project for you(far be it for me to guess at your motivations for this sorta thing 😉 )... it'll end up being even more code you have to support.

would love for the

request.testbox

stuff to work, it seemed like a great idea that wasn't able to quite get off the ground

already has issues created AFAIK

(don't wanna be a nae sayer, and also not simply being a contrarian. Just offering my thinking when I see a feature in front of me, and also as probably one of the heavier TestBox users out here)

@sknowlton what is this

request.

you speak of? 😉

https://ortussolutions.atlassian.net/browse/TESTBOX-281 https://testbox.ortusbooks.com/in-depth/output-utilities

there's a special limbo where Ortus bugs marked as 'resolved' but aren't resolved go, but Luis a few times a year puts on a big bullseye and runs around asking for people to shoot him so they always get taken care of...looks like today's the day. 🙂

LOL

Reopened

I thought I had reopened the ticket, yet I missed it

And @Adam Cameron yes to all the bugs and performance issues. However, gauging interest for new features as well

Trying to see if this would be beneficial for folks, or just a nice thing to have

I know that right now, I am attacking a few items directly: • Known bugs • Performance • Ability to do dry runs, so it can be used by IDEs and CLI • WireBox integration to support Modules • New testing UI experiences • And new VSCode extension which is partially finalized that will support jumping, highlighting, running, etc • Inline Datasets for iteration and calling • Some new matchers (toStartWith, toEndWith, and(), when(), unless() ) • Skipping function (skip (message ) ) • Localized before/afterAll by Suites

(yeah I was not giving you the hurry up or anything, just giving my notional focus priority)

WireBox integration to support Modules

If you do this... do me a favour? Keep it well separate, and as a separate module like ortus.testbox.wireboxIntegration or something. Why I say it is I see a lot of libraries that are written by CB users that have CB stuff hard-wired into them, where the better approach would be to define interfaces and accept [some manner of object that does this thing]. There's no way there should be any framework (or DI library!) plumbing inside a well-written library-that-works-with-this-framework\

If you see what I mean.

It’s basically to support modules, so people can extend TestBox, in a modular fashion

In order to do that, there has to be support for DI

so each module can interact with it’s dependencies

What CFML "needs" is this: https://www.php-fig.org/psr/psr-11/