Hi all, I'd like to create functional tests for my Iliad apps. I'm thinking along the lines of subclassing TestCase, have it create a new application instance and use its methods to 'click' through the UI, then use assert: equals: to test for content in the resulting UI state (and perhaps model content). It seems straightforward to do this with full HTTP requests and then parse the resulting DOM since Iliad will render full HTML pages for js-disabled clients. But I'd prefer if I could do it more fine-grained, testing the app in memory for UI content. My reasons for that are 1) speed and 2) being able to navigate the stack trace to my app's code in the debugger when an assertion fails. Thanks in advance for any hints! cheers, Siemen You received this message because you are subscribed to the Google Groups "Iliad project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Hi Siemen,
seems like an interesting subject but I don't have any hints as to how to do it. I am still struggling to get into the habit to allways create units tests first... Well, let's think about it. If I have to do functionnals tests in my Iliads apps, I wouldn't do it with UI content, but just test the actions methods on which I link all actions offered to the website/webapplication user. Moreover as you posted on the Pharo mailing list, I am not sure about the current support of JS-disabled in Iliad. It was one thing I considered nice 10 years ago when I first tried Iliad, but for the last few years I stopped thinking about it as I made the choice of using Iliad only for "webapplication" and not for website. And for webapplication I can't get the UX I want without the JS. @+ Benoit Le 19/02/19 à 21:10, Siemen Baader a écrit : > Hi all, > > I'd like to create functional tests for my Iliad apps. I'm thinking > along the lines of subclassing TestCase, have it create a new > application instance and use its methods to 'click' through the UI, then > use assert: equals: to test for content in the resulting UI state (and > perhaps model content). > > It seems straightforward to do this with full HTTP requests and then > parse the resulting DOM since Iliad will render full HTML pages for > js-disabled clients. But I'd prefer if I could do it more fine-grained, > testing the app in memory for UI content. My reasons for that are 1) > speed and 2) being able to navigate the stack trace to my app's code in > the debugger when an assertion fails. > > Thanks in advance for any hints! > > cheers, > Siemen > > > -- > You received this message because you are subscribed to the Google > Groups "Iliad project" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [hidden email] > <mailto:[hidden email]>. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Iliad project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Hi Benoit, thanks for you reply to both of my questions. Sorry it took me long to reply. I'm developing a layer on top of Iliad that allows me to put rendering directives into plain HTML (similar to Angular) and use an external web editor to iterate the UI with users. They don't understand tag brushes, but they recognize rendered static HTML in a browser. I'm interested in functional tests because I constantly abstract functionality from my apps to that layer, so I have to test a number of Iliad apps that depend on it... So that's why I am testing at the UI layer. That's my context :) Your response made me look at ILWidgetTest >> #withSessionDo: . It is possible to build widgets and hence applications without writing them out to a HTML string if you provide an ILRequest and ILSession. This is what I am pursuing now, traversing the built (but not serialized) application #page #html for elements that have an #onclick attribute, then executing the associated actions, and testing UI content. It's not working yet, I have problems with the #withSessionDo: code instantiating a whole new application object during the tests. But I think it will succeed when I figure out how to register the instance of the currently tested app in the session registry. Thanks for answering my previous questions, it was helpful. cheers Siemen On Wed, Feb 27, 2019 at 12:40 AM benoit <[hidden email]> wrote: Hi Siemen, You received this message because you are subscribed to the Google Groups "Iliad project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
Free forum by Nabble | Edit this page |