Can anyone think of a way to create a query object which has spaces in the column names? Backfilling tests on some old code before I refactor and it seems that cfspreadsheet when reading to a query object will handle spaces in column names which I want to mock.

What's the proper way to use

beforeeach

in a given-when-then block in TestBox? It does not work like describe/it. I've tried it inside

story

and inside

given

and neither seem to do the trick.

How does one mock a function (not a method) with MockBox. IE: a function that's just in a library .cfm file instead of a method in a .cfc:

<cfscript>
// MyCoolLibrary.cfm


function testMe() {
    if (avoidRunningMe()) {
        return "one fish"
    }
    return "two fish"

}

function avoidRunningMe() {
    // really slow or is destructive or has external dependencies or something
}
</cfscript>

The library is just included when one wants to use it, eg like this:

describe("Testing MyCoolLibrary", () => {
    include "MyCoolLibrary.cfm"
    it("checks testMe does the right thing", () => {
        // now I need to mock avoidRunningMe before calling testMe...?
    })
})

TestBox observation. And I'm wondering if this is a design bug. The

beforeAll

/

afterAll

lifecycle events are handled via defining a function of that name, and they run once per test bundle file (https://testbox.ortusbooks.com/in-depth/life-cycle-methods/bdd#beforeall). In other spec-driven testing frameworks, these lifecycle events are specific to the organisational block they are within; eg each

describe

block can have its own

beforeAll

handler, just like it can have a

beforeEach

handler. I've verified this on Jasmine, Mocha and RSpec. The docs on Jest are unclear, but I think they work the same way as TestBox. My own expectations are that TestBox ought to work the same as Jasmine, given TestBox is very very similar to it in many regards. And there's a good argument to be had that RSpec is the one to follow for one's expectations for this style of testing framework. Thoughts? (also ping @lmajano)

Thanks for pointing that out @Adam Cameron I think this can be a feature to add. When I created TestBox, Jasmine didn’t support much life-cycle events (2013). They started introducing life-cycle events late 2014. Jasmine and Mocha where my initial inspir;ations. With that said, I see value in adding localized

beforeAll()

and

afterAll()

to

describe(),story(),feature()

blocks

Hey if y'all have a moment, could you let me know how many unit tests you have for the app yer working on, and how long it takes TestBox to run them? NB: specifically unit tests. Not tests that hit external services / DBs etc. Just tests that are exercising algorithmic / business logic, not network connectivity. And specifically TestBox. Cheers.

I'm curious to know what folks are generally using for Performance Testing and Load Testing with Jenkins CI/CD. What are your thoughts regarding JMeter, K6, LoadView, or Gatling?

I wonder what you think about a probable design shortcoming in TestBox's SimpleReporter (ref: https://github.com/Ortus-Solutions/TestBox/blob/v4.5.0/system/reports/SimpleReporter.cfc#L71)

@johnbarrett I keep a fairly close eye on this subchannel & am reasonably experienced with TDD / testing / TestBox so ping if you need help.

This might be a dumb question, but is there a good way to test private methods with testbox? Or should I just stick to testing the public stuff and ignore all the in-between steps?

This is not gonna be great to track down. Consider this test:

it("fails if an exception is thrown", () => {
    expect(() => {throw "hi"}).notToThrow()
})

This should fail. On Lucee 5.3.7.48 it works fine. On Lucee 5.3.8.206 it doesn't work. IE: this test passes. It also passes if I use

toThrow

instead of

notToThrow

. I will try to track it back to a specific change in Lucee, but I suspect something woolly is going on in the TestBox code that makes it fragile. NB: that is just a distilled-down repro case. My actual case was with an expression that resulted in an exception, and I tried with various other expressions that caused exceptions. All behave the same:

toNotThrow

does not work. Ping @lmajano

Probable TestBox bug. Just sanity checking it before I commit to raising it. I've seen what seems to be some incorrect behaviour in the

notToThrow

matcher. Here are some tests: https://gist.github.com/adamcameron/e1674e216bd8b759fb34e663fc8a6603

Didn't test that test string in my test, did I? HA

Bug raised for TestBox which is broken for the

aroundEach

case that I mention therein. https://ortussolutions.atlassian.net/browse/TESTBOX-351

This is excellent stuff @Adam Cameron Take my karma already (if I could give any!)

Any reason what this demonstrates is not a TestBox bug:

describe("Tests of testBox's toHaveKey", () => {
    it("is a control test", () => {
        st = {key="value"}
        expect(st).toHaveKey("key") // pass
    })
    it("handles a key with a null value", () => {
        st = {key=javacast("null", "")}
        expect(st).toHaveKey("key") // The key(s) [key] does not exist in the target object. Found keys are [[KEY]]
    })
    it("demonstrates the key does in fact exist", () => {
        st = {key=javacast("null", "")}
        expect(st.keyArray()).tobe(["key"]) // pass
    })
})

Same behaviour in CF and Lucee. (ping @lmajano)

this reminds me of this thread, where I was forced to eat my words.... https://cfml.slack.com/archives/C06TABBT8/p1650922356951229

StructKeyExists

returns false if the value of the key is null.

I suppose that's probably the reason for the bug... whether TestBox should implement a different check for

toHaveKey

is worth a discussion, but I can see the argument for "`toHaveKey` should return the same thing as

keyExists

."

Yeah, I was not sure, hence the Q. I can see arguments both ways. Was easy enough to work around, so I'm not so bothered I guess.

I kinda hoped TestBox wouldn't be as rubbish as CF & Lucee here. But at the same time it makes sense that it does mimic their behaviour.

Yea, I see the issue

I think we can improve on the lucee/adobe crap where the

structKeyExists()

is not returning

we can use the

keyArray()

and test that

instead of checking the existence in the struct