I have been testing .cfc components with TestBox b...
# testing
b
I have been testing .cfc components with TestBox but now would like to test a view (.cfm file). I know I can use an include statement to bring in a view file, but how do I reference elements and assert they exist or not on the page?
b
testing a CFM can be much harder, typically due to the lack of encapsulation
Generally, you can include them and • verify the variables scope has the expected data • verify the output via save content
I don't typically test cfm in a test suite-- I would use integration testing in a framework like ColdBox to verify view renderings
a
I would actually question the merits of testing views a) at all; b) via TestBox. If one decided one needed to test the UI, I'd use Playwright or Cypress.io or something.
ā˜ļø 2
šŸ‘€ 1
(that is no slight on TestBox when I say that, btw)
b
Agreed. If you don't have an MVC framework that allows integration testing, Playwrite or Cypress is the next best thing (perhaps better depending on what you're after)
šŸ‘ 1
a
(well yeah I was about to say that)
b
I see. Use case is I need a certain set of tabs to show up on the page if a user is of one type and a second set of tabs if they are of another type. Maybe I just shouldn't test this (I know UI testing gets messy). And ok on playwright or cypress - yeah I'll start looking at those and getting that set up
a
Good skills to acquire if you have the time to do so. I've not used Playwright and only supervise our QA who uses Cypress.io, but it's amazing what they can do, with minimal effort. Starting again I'd run with Playwright though I think. By all accounts, by being second to market, it learned a lot from some "interesting" decisions / approaches that Cypress took. We use Symfony as our framework, which - like ColdBox - has functional testing stuff built in, and plugins for PHPUnit etc, but it is sooooooo primitive compared to a framework that actually embeds a virtual browser and lets it run JS and CSS and has a proper DOM etc.
b
Good info. I have heard from many people that playwright is even better than cypress so that's where I'd start. It seems to be the current go to tool for this kind of testing from what I can gather.
b
@elpete Worked on a TestBox integration with Playwright (use your testbox tests to control the playwright stuff) but I'm not sure what state it's in currently
šŸ†’ 1
d
Crude tests like findNoCase("Tab 1", pageContent) (which will no doubt rightly horrify most everyone here), might work just to verify that the logic bits driving which tabs show is correct. But I'd test that logic directly, writing tests for getUserTabs(), instead of testing what the rendering logic does with that result. Real UI testing is a bear IME, very brittle, gets broken by irrelevant DOM and browser changes, maintenance nightmare. I haven't been involved w these more recent UI testing tools, so maybe the world is a kinder place by now, but back in the Selenium days it was No Fun.
šŸ‘ 1
a
We've just switched from Cypress to Playwright - I'm really impressed with Playwright (and I liked Cypress)
šŸ™Œ 1
šŸ‘ 1
b
Yeah what I've read in some books is a recommendation to test a thin API layer that your view calls instead of the UI itself. Also something something "humble object pattern".
a
We use Playwright via node - the work elpete did is good but a right pain to work with as it's using a java wrapper so ACF sulks ALOT! It worked better in Lucee, but that's not our stack
šŸ‘ 1
a
I don't really know what a TestBox wrapper for Playwright actually gives, given the node runner is just... easy. I mean I don't know shit about node or (in our case) Cypress, but I was able to get our test env dockerised and running in a few hours. It's poss a "if yer only tool is a hammer, everything starts looking like a nail" sorta thing.
And it's a more portable set of skillz to have than "I know how to run Playwright via TestBox", which most ppl will go "um... but why??" at.
(I'd say the same thing about someone trying to do same in PHPUnit or via Symfony etc. Just... not a great approach, and again no slight on TestBox)
b
It might even be a good excuse to introduce node via a tool chain like vite or parcel šŸ¤”. I've had some success adding them to a PoC based on the structure of the app I'm working on.
a
^^^
a
> I don't really know what a TestBox wrapper for Playwright actually gives, given the node runner is just... easy. I mean I don't know shit about node or (in our case) Cypress, but I was able to get our test env dockerised and running in a few hours. Yeah - agreed for UI testing. I looked into it as we use Playwright to capture JS charts etc, so was a use case for using it from CFML. For actual end-to-end tests we run direct from node
b
The TestBox wrapper wraps up the Java library, which has nice tools for auto-downloading the browsers. it makes the Java wrapper easier to use and if someone already has a testbox test suite stood up, it may be simpler and easier to just plug the playwright tests into that instead of needing to setup a separate test runner. Here's a preso on it from a couple years back https://cfcasts.com/series/itb-2022/videos/eric-peterson-cbplaywright-end-to-end-tests-with-playwright-and-testbox.
image.png
b
Good to consider options, ty for the info šŸ™
šŸ’Æ 1
a
Real UI testing is a bear IME, very brittle, gets broken by irrelevant DOM and browser changes, maintenance nightmare. I haven't been involved w these more recent UI testing tools, so maybe the world is a kinder place by now, but back in the Selenium days it was No Fun.
They are much better - they tend to rely on accessibility roles etc. So your tests are more like
get me an element with role of button with text go
instead of selenium days of
body > .content > li:nth-child(3) > button
šŸ‘ 1
Also means you end up with more accessible web pages so win win!
šŸ‘ 1