https://linen.dev logo
Join Discord
Powered by
# haxe-ui
  • b
    great! trying that out rn
  • h
    When you say automated, what do you mean exactly ? Does this integrate with utest ?
  • l
    you basically write a program running a bunch of unittests, only those unittests communicate via websocket with your (slightly modified) HaxeUI app. unittests can send mouse events or read/write any property of your HaxeUI components.
  • l
    so you can check whether your app does the thing when you push the button that should do the thing.
  • h
    Had more of a look. So it looks like the client is utest based which works for me. I assume it's called haxeuim because it works a bit like a selenium web driver ? I have a flixel/ haxeui app which I want to write tests for. This could be very useful.
  • l
    yes, currently there are some 
    Assert.fail
    calls in haxeium, that are tied to utest lib, but I guess those could get removed / changed to something more universal. then you could write unittests with whatever testing framework.
  • l
    and you guessed it right it's like selenium bug for HaxeUI projects.
  • h
    I think I'd like to see if I could deploy the app piece via a macro or something so I can turn it on off easily and exclude from release builds. Will have to play
  • h
    I prefer not to mod the prod code for testing but limit it to injection or something
  • l
    yeah, I would prefer an unmodified release version as well, but there needs to be some amount of code that talks to the test app, so it's kinda unavoidable
  • b
    @bright-gpu-74537 i think you forgot the code behind in sidebar example? 🙂
  • h
    I've used macros to replace a function and have it install test support which does some test specific thing and then calls the original function. Hopefully something like that would work here
  • l
    as far as I know there is no macro magic in play for the in-app part, just the driver and a websocket thread, so there should be no conflict or blockage when using macros
  • b
    i was playing with the sidebars a bit and it affected the tooltips o_O

    https://i.imgur.com/7p4uGei.gifâ–¾

  • b
    what, what? How did that happen?
  • b
    right, yeah, looks that way
  • b
  • b
    very very cool - will have to play - i tried to do something similar (using a cucumber type language to write the FTs) - i got it working for the most part - though just briefly looking you system looks alot fuller
  • b
    how are you simulating mouse clicks / keyboard input?
  • b
  • l
    I'm using 
    component.dispatch
    to send 
    MouseEvent
    objects, keyboard input currently not supported, but should work similar. you can set 
    text
    properties (although that's not the same as keyboard input).
  • b
    right, so you are dispatching mouse events to the UI using its its own event system
  • b
    i wonder if there is merit with using something like the "input simulator" to make things more "real"
  • b
    or maybe like a plugin system where you can choose from different methods...
  • b
    either way, super interesting stuff... nice one... look forward to playing with it
  • l
    yeah it requires code to be embedded with your app, which is not ideal, because it's not production code that's getting tested. also using events might give a wrong impression of a thing working, when the real thing won't, because for e.g. a component might be covered by something so won't receive a real click but will happily execute its event handler.
  • b
    > component might be covered by something so won't receive a real click this is a very good point
  • b
    cool stuff anyway - would be really nice (one day!) to have suite of functional tests that run on GH
  • l
    not sure if Github Actions allows apps with windows to run, they might all be headless build agents
  • b
    hmmm, yeah, another valid point
1...119011911192...1687Latest