91–100 of 109 posts
Looks cool for really simple things but wouldn't use it for anything serious. I have been using Cypress[0] the past few months and so far I've been quite pleased with it. [0] cypress.io/
Is it suitable to do automation? They seem to be mentioning testing only.
Earlier quoted context omitted.
All these kinds of HN comments share the same flaw: they unnecessarily detract from the work the OP has done by attacking use cases that the project never claimed to solve. DSL's, for all their problems, do simplify complex programming logic, and people use them every day to do great things. DSL's like Ansible and Chef save people an order of magnitude of time for server provisioning hence why they are wildly popular…
Some of us legitimately believe DSLs are rarely the right choice. We don’t say this to shit on people’s work, we say it to kick off a conversation about API design. I’ve written DSLs in the past. I was a Rubyist! I have come to some perspective on those choices in the intervening years. I’m a big fan of functions that take arguments, and I am skeptical of hidden shared state.
Earlier quoted context omitted.
I wonder why don't use Puppeteer[1], which is a established project for automating Chromium using Chrome DevTools protocol. [1]: https://github.com/puppeteer/puppeteer
Taiko was initially based on puppeteer, but it was hard to keep up with puppeteer's api changes. Plus, the abstraction leaked. Taiko is now built on the excellent https://github.com/cyrus-and/chrome-remote-interface
Probably a 10 minute job to set up some basic commands (like demoed here). Not saying you can replace this project in 10 minutes of course.
Advantage is you can use the same language as used here pretty much, but you can use some of gherkin's nice features like the tables for different test cases (or scraping cases!).
Kasaya would have the role in this case of defining the common language.
Earlier quoted context omitted.
Seriously, how is this DSL better? With JavaScript you get method completion and debugging. Are parentheses really so terrible? You can setup a DSL in scala.js and you can get the best of both worlds (though, parentheses are fine for me so I would just use one of the many fine existing JS libraries).
> With JavaScript you get method completion and debugging. a) now your QA team needs to know JavaScript b) method completion is crap when you don't know the language. c) "You can setup a DSL in scala.js and you can get the best of both worlds" OMG You want to add Scala to the mix too? AND write your own DSL from scratch, and take on its maintenance to support your QA team's needs instead of leveraging an existing one…
The library authors can use those the create a better DSL (or as I call it: "just a good API"). the cognitive load on the users is the same, only it's easier to setup up proper tooling
in javascript you can make the exact sample api he defined only with `await` and some parentheses
in scala you can setup API that looks like: `browser show page`, users don't really learn scala just write the same commands they otherwise would (I'm not saying you should do this. You could, if you really hate parentheses for some reason, but there is a way about it without inventing your own ecosystem)
Earlier quoted context omitted.
FYI to avoid all those awaits and make it chainable you can wrap it in a Proxy. https://github.com/kozhevnikov/proxymise
Or ppipe, if you want more features (I'm the author): https://github.com/egeozcan/ppipe
Dragging is a command I wish existed. I’m not super sure how to test draggable components - any thoughts?
Test automaton guy here. Why reinvent the wheel? Selenium/WebDriver is already a standard ( https://www.w3.org/TR/webdriver/ ). It has years of maturity. Maturity means that through use and development iterations it can now cater for a lot of corner cases. How to do domain authentication in IE. How to handle all the different types of modal dialogues. And so on. It can be used in several different REAL programming la…
I'm currently developing a test automation DSL as part of a full automation service. My partner worked for some time running on-site test automation courses. This was for organisations where the devs were average 9-5 workers without any passion for software development. Not the sort of places that would ever feature on HN. Manual testers transitioning to automation testers within such organisations are, in most cases…
Where I'm coming from is having seen some tool vendors sell "scriptless" test automation tools. UFT has it, and what used to be Rational Functional Tester has it (I peddled RFT in a previous life). The vendors sold it very successfully to non-technical managers, and it looks cool, the dusty companies and large companies all fell for it. "Your Business Analysts can automate tests". But a few months down the line, you realise that it is a rock muffin. No modular code, but linear end-to-end scripts. The login page changed? Update hundreds of test scripts. Who looks bad? Test automation as a profession.