> pronounced Kuh-SAA-yuh That's ambiguous and not helpful – particularly in English that has many varieties and also too many vowel phonemes to map onto letters. Use IPA instead.
For anyone else wondering, IPA = International Phonetic Alphabet.
Show HN: Kasaya – A scripting language and runtime for browser automation
101–109 of 109 posts
Re: Show HN: Kasaya – A scripting language and runtime for browser automation
#102Earlier quoted context omitted.
> Edit: A killer feature would be autocomplete for things found on the page. Challenge accepted!
IMHO it would also benefit from a "raw typing" mode. It's a bit silly to have to explicitly write 'type "cat"' and 'press "enter"' , when you're already typing 'cat' and 'enter' . You could simply start this raw mode with a keyboard shortcut, and everything you type is automatically transformed into this "type" and "press" commands, until you exit the mode with either the same shortcut or Esc.
Or if the first thing you type is a quote if you are focused on an input, then it infers the type command, otherwise it's a focus search.
Re: Show HN: Kasaya – A scripting language and runtime for browser automation
#103Earlier quoted context omitted.
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…
I take your point, and kudo's. 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…
I certainly feel your pain when it comes to non-modular linear end-to-end scripts.
The DSL I'm working on is already quite modular so as to reduce repetition, to hide complex-looking things like CSS selectors behind user-defined names and to support the definition of data sets independent of the tests that use them.
A test for a given page can import test steps, adding further actions and assertions if required and injecting one or more sets of data over which to iterate.
Sets of data can be defined inline (to support quick learning) or defined in separate files and imported and referenced (more ideal).
Properties of a page being tested can be defined separately to the test itself, including aspects such as the URL and named locators expressed as either CSS selectors or XPath expressions, referenced later as needed by the user-defined name. This reduces to one the number places many page-specific details need changing, as well as allowing the tests (which reference by name pre-defined locators) to flow more naturally.
I'd greatly appreciate your feedback in a few months when we have something workable to demonstrate. My email is in my profile if you're happy to help.
Re: Show HN: Kasaya – A scripting language and runtime for browser automation
#104Earlier quoted context omitted.
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.
You can be skeptical of DSL's but still recognize that they provide a time/complexity trade-off. I agree that it's probably not the right decision to write your own DSL for something but to dogmatically crusade against all DSL's feels silly to me when there are so many popular projects using them. Ansible is popular because it is accessible to devop type roles (previously known as sysadmin or IT services) that may kn…
> they provide a time/complexity trade-off
I think that’s too specific of a claim for such a broad category as DSLs.
I think in specific cases there is a time-complexity tradeoff you can exploit, those are the (IMO extremely rare) cases where a DSL is worth considering. But in a lot of cases it’s just added complexity. Functions are pretty powerful.
And they are also easier to reason about. Often the DSL adds “time” because you’re like “why the heck isn’t this working” and it’s because of some weird state you can’t inspect that’s deep inside your parse tree. “Guess I better start reading the source code of my DSL runtime. Oh look, someone hacked a corner care into the parser.”
My rule of thumb would be something like:
1) if you have time to make your DSL superbly executed, and 2) you are very certain it can make an entire class of problems go away, and 3) you don’t expect weird corner cases to ever show up in a future project that break the model ...then it’s worth considering.
As a professional coder though, I don’t see a lot of situations like that. In particular the “build this module superbly” is generally not an option on the table. Nor is “you can model the domain of future needs thoroughly” But I work at startups, I bet at a BigCo if you are a very senior person DSLs are on the table more often.
Re: Show HN: Kasaya – A scripting language and runtime for browser automation
#105Earlier quoted context omitted.
You can be skeptical of DSL's but still recognize that they provide a time/complexity trade-off. I agree that it's probably not the right decision to write your own DSL for something but to dogmatically crusade against all DSL's feels silly to me when there are so many popular projects using them. Ansible is popular because it is accessible to devop type roles (previously known as sysadmin or IT services) that may kn…
> they provide a time/complexity trade-off I think that’s too specific of a claim for such a broad category as DSLs. I think in specific cases there is a time-complexity tradeoff you can exploit, those are the (IMO extremely rare) cases where a DSL is worth considering. But in a lot of cases it’s just added complexity. Functions are pretty powerful. And they are also easier to reason about. Often the DSL adds “time”…
Your whole argument boils down to "use a DSL only when appropriate" - no argument here on my end.
Still, I don't think that makes a DSL a bad fit for this specific project, even by your own standards.
> 1) if you have time to make your DSL superbly executed, and 2) you are very certain it can make an entire class of problems go away, and 3) you don’t expect weird corner cases to ever show up in a future project that break the model ...then it’s worth considering.
#1 yes, just like any code you write, right?
#2 yep, this is the same thing as complexity/time trade off
#3 maybe? you can still have edge cases that you can't solve with your DSL but that doesn't invalidate its usage if the benefits from #2 are great enough.
And #4, which is the biggest reason and the reason to use it on a project like this: it provides a more accessible interface to your project for a broader audience of people.
Re: Show HN: Kasaya – A scripting language and runtime for browser automation
#106Why is Java SDK needed?
Re: Show HN: Kasaya – A scripting language and runtime for browser automation
#107This is neat. I was just looking for something like this the other day. Does it support loops? I don't see any example like that. Basically I wanted to load a search results page and check something about each of the results on the page.
Our current thinking is to not provide branching mechanisms (loops, conditionals) by design. Both to keep the language simple, but more importantly, to force script writers to create one test per each scenario. If you need an if statement, that's probably an indicate you need two tests.
For your use case, you'll need to write a macro and then call it the number of times you need.
how to check for $something in search results for $thing
...
end
check for "foo" in "bar"
check for "foo2" in "bar"
check for "foo3" in "bar"
Re: Show HN: Kasaya – A scripting language and runtime for browser automation
#108Earlier quoted context omitted.
I take your point, and kudo's. 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…
I certainly feel your pain when it comes to non-modular linear end-to-end scripts. The DSL I'm working on is already quite modular so as to reduce repetition, to hide complex-looking things like CSS selectors behind user-defined names and to support the definition of data sets independent of the tests that use them. A test for a given page can import test steps, adding further actions and assertions if required and i…
So is mine. Send me a link when you have something.
Re: Show HN: Kasaya – A scripting language and runtime for browser automation
#109Earlier quoted context omitted.
I certainly feel your pain when it comes to non-modular linear end-to-end scripts. The DSL I'm working on is already quite modular so as to reduce repetition, to hide complex-looking things like CSS selectors behind user-defined names and to support the definition of data sets independent of the tests that use them. A test for a given page can import test steps, adding further actions and assertions if required and i…
So is mine. Send me a link when you have something.
Your email doesn't appear to be present in your public profile that I can see.