Hi, I think what we have currently with selenium is just some setups and few tests. The problem with tests is that they need a lot of time in coding and when running a build. But for me the main problem is the first one. I think integration tests are used to discover regressions sooner and better than unit testing. Don't get me wrong, unit testing is as well needed, of course, but I think are better (in our case) to detect regressions in compiler, or things like AMF encoding/decoding regressions and more. For components and framework things integration tests seem to go directly to the problem.
When I tried to code some integration tests for TDJ, I found it wasn't easy. The problem is it goes very close to the final output (raw). So you have to deal with input, span, and things that are very low level for us. For me the ideal to code a good integration test (don't mind the final tool we choose), is to be able to code some counterpart framework for our components sets (basic, jewel,...) so I can code what a jewel button must do easily and that translates easily to the low level raw code we output. I think that will be something really usable and doable, since in the current state, I think our integration tests are really not accurate at all. For now we have just some set up, but we don't have a real integration test suite that covers examples and shows regressions. So, IMHO, we have lots of work on that side, maybe not to do now, but as we have some time to learn about it, it would be good to see other solutions and see what could solve the problem in a real way. just my 2 Carlos El lun., 15 jun. 2020 a las 14:18, Christofer Dutz (< [email protected]>) escribió: > Hi Harbs, > > well it's not entirely not-broken ... that's why I brought it up. > > Currently Infra seems to need to run the Jenkins Agents on windows in a > way that is way less reliable. This is due to the fact, that selenium needs > an interactive session to run the browser tests. If we were able to get rid > of that, Infra could use the more stable way as a windows service. > > Also there's always quite a mess with keeping the webdriver version in > sync with the used firefox version. This also seems to be no problem > anymore with cypress. > > Chris > > Am 15.06.20, 13:20 schrieb "Harbs" <[email protected]>: > > In the JS world, there’s a new cool way of doing things every year or > so. > > My opinion on these things is “if it ain’t broke don’t fix it”. Why > switch from Selenium if it works? > > If we have a good technical reason to change things, I’m, open to hear > the arguments. Otherwise, it’s just going to waste all of our time… > > I definitely don’t want to add full browser testing as part of the > testing of the framework build. It takes long enough as-is. > > There might be some value in adding a SEPARATE testing suite which > tests multiple browsers, but I think we have a lot of work in increasing > our UI test coverage before we even think about that. > > My $0.02, > Harbs > > > On Jun 15, 2020, at 1:59 PM, Carlos Rovira <[email protected]> > wrote: > > > > Just had a conversation with a Red Hat friend and told me that they > use > > Jest (https://jestjs.io/) > > seems they are happy but don't know much more about it, or if > cypress is > > more advanced. > > What seems to be clear is that selenium is something old these days? > > > > > > > > El lun., 15 jun. 2020 a las 12:38, Carlos Rovira (< > [email protected]>) > > escribió: > > > >> Hi Chris, > >> > >> didn't know it. From the video in the home looks promising :) > >> One thing I'd like to have for a ite-test solution would be to code > some > >> component place holders so we can code in a more abstracted way > than going > >> directly to the html/js specific code that royale outputs. > >> Hope cypress could do something in that way that makes the coding > >> integration test easier :) > >> > >> > >> > >> El lun., 15 jun. 2020 a las 10:02, Christofer Dutz (< > >> [email protected]>) escribió: > >> > >>> Hi all, > >>> > >>> I just had a chat with a colleague of mine … he’s using cypress.io > for > >>> UI testing and it does seem that it has quite a number of > advantages over > >>> selenium. > >>> Coolest thing is that it seems to support multiple browsers, one > of them > >>> being electron which seems to be ideal for testing UI stuff on > headless > >>> systems. > >>> > >>> Perhaps with this we can remove the requirement to have Jenkins > started > >>> in a special way on the Windows build machines. > >>> > >>> Just wanted to drop this here :-) > >>> > >>> Chris > >>> > >> > >> > >> -- > >> Carlos Rovira > >> http://about.me/carlosrovira > >> > >> > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > > -- Carlos Rovira http://about.me/carlosrovira
