What if cucumber and jQuery had a baby? | Hacker News Reader

What if cucumber and jQuery had a baby?

github.com

52 pointstswicegood30 comments

I'm in QA - what niche does this fill for you?

The reason that I ask is that usually DSLs and other user acceptance tools exist to allow non-programmers to design tests. That is why cucumber's Gherkin is not in a Ruby syntax, and why robot and FitNesse use html tables. And further, they generally operate at an integration level, which is why the have hooks in for like Selenium frequently.

I think the project is cool, but I do wonder where you see it fitting in. A way to make jsunit tests more readable and cleaner?

EDIT: Let me add that I love it whenever QA topics make it to HN. I know QA is usually a post-seed funding activity, and that's a shame (in my biased opinion).

I don't know, it could be cool as a way to put the scripting of the user interface into a language that less technical people could understand and experiment with. Hopefully you aren't writing thousands of pages of this stuff (instead you should find a way to put together abstractions that reduce the amount of code that has to be written at this level) but it would be great to have a lot of the scripting of a UI be 10 or 30 or 100 pages of stuff that reads just like English.

That's my thought, anyway.

No, I agree completely.

My gripe is that the DSL is JS with a fluent interface. You need a DOM context in order to make JS work (unless I'm mistaken) which is why you have tests that drive the browser like Selenium. So you are going to write Javascript in order to drive some other tool that interacts with the AUT.

Anyway, it's neat, and I'm not trying to discourage anyone.

I don't think this has anything to do with QA or testing. Just another way to write javascript inspired by the cucumber DSL.

Cucumber is a BDD tool. That stands for Behavior Drive Design, which is what the 'when X expect Y' format is. It's intrinsically a testing tool, where the user acceptance tests are described in a BDD format. It's a subset of TDD.

You are correct in that cucumber is a testing tool...

What is in that repo on github "whenever.js" is not for testing and is not BDD for js or jquery. The author implemented a dsl like cucumber to allow creation of behavior in javascript.

Fair enough - I'll call it a failure of imagination for me, then. I saw a DSL that had a BDD syntax for javascript, and thought it was meant to be some form of testing tool. We all have our cognitive blinders :)

For the record: this was a thought experiment that I made on the plane home from TXJS last week and was just something I wondered if I could do.

The reference to cucumber is really only a nod to inspiration for the given / when / then syntax, and the emphasis of speccing behavior in plane English.

I've also been fascinated by the idea of writing executable English as implementation logic, and since JS allows object labels to be strings, why not make full descriptive sentences.

I haven't used this for anything useful or practical (it's days old) ... but I'm hoping it will be a neat way to spec and as someone mentioned document the behaviour of my app and to try and try to separate the intent of what I'm writing from the implementation.

Nice idea, but what does this actually do for you? If you translate the first example to straight jQuery, it's shorter, and you don't need to know about 'whenever' to figure out what's going on. And even if you were familiar with 'whenever', you'd have to look at three different places to understand what the code is _actually_ doing.

What's cool, I think, is the chaining of predicates. That's useful in general, and should be a totally different library.

Given that I really don't have any practical experience using whenever.js (it's literally days old) my "argument", is that jQuery tends to be very syntax heavy.

eg. jQuery('a#click-me').click(function(){ $(this).text('Clicked!') })

... there's a lot of cognitive work going on here. Not only am I parsing javascript, as a coder, I'm parsing the CSS of the selector, and creating a mental model of the anonymous function. It's not to say that this is necessarily a bad thing, just that there's a lot of extra syntax to handle.

whenever("Click Me!").is('clicked').then('change it to "clicked"')

...reads without all of the extra syntax, but it still remains valid javascript.

> you'd have to look at three different places to understand what the code is _actually_ doing

This is a fair point, but I would argue that for most code you read, there's typically nowhere to go to find out the _intent_, which for me is really the most important thing. I think it's fascinating to be able to have "executable intent" ...

... but since I don't really have any real world experience using this, I can't really back up my arguments with any real data ... just the motivations I had to write this!

Here's what you can do without using whenever that addresses your issue, and possibly others'. As far as I can tell what people don't like is the inlined function. You can get rid of that and be descriptive about what's going on, all without the use of whenever:

  whenever("Click Me!").is('clicked').then('change it to "clicked"')

turns into:

  var cbs = {};
  cbs.setClickedText = function() { $(this).text('Clicked!'); };

  $('a#click-me').click(cbs.setClickedText);

Yep, I've played around with tons of approaches to this problem : your solution is where I started. It's probably totally ok, but there was something about it that just didn't sit right with me.

In eyeballs.js, for examples, I explored doing all of the binding via the html elements themselves, eg:

which would map to a pre-defined posts controller new action.

whenever.js is just another exploration along the same theme. Again, I'm not arguing that it's better or worse: just my motivations for making it.

So basically I need to program everything twice in order to do anything? And changing anything means going to three different places in the program?

No thanks.

I can see this as a useful tool in prototyping. You can create these short DSL phrases to describe the behaviour you want, then implement as much as you need.

The other benefit is the documentation (in DSL form) you get. It's always nice to have concise descriptions of your application's behaviour.

If you're as confused as I am, "cucumber", in this case, is referring to a testing framework for ruby, not a vegetable.

https://github.com/cucumber/cucumber/wiki/

a side note: am I just totally out of touch with things? "Fructose", "Cucumber", "Coffeescript", "V8"?

One explanation: Totally out of touch.

Another explanation: Modern-day web developers are obsessed with branding, and mistakenly think that a clever (read: opaque) name and good logo are just as important as utility value.

This probably started with jwz/Mozilla. Sometimes it works.

The utility value of cucumber, coffeescript and V8, to a great many people -- perhaps not to you -- is pretty much undeniable.

Reminds me of Hypertalk and Metatalk. I personally don't like such verbose syntax, but many do. It's usually used in marketing languages to non-developer professionals, however, in the end, I feel it becomes way more verbose and complicated than if you used the conventional concise approach.

I used to joke that when using one of these scripting languages you would have to start your statements with "please" and end with "thank you".

It may turn out to be too verbose, but in terms of my motivation, and conciseness vs. verbosity, the goal was to achieve:

1) conciseness of expression of intent ... I feel that this is the most important thing to get accross 2) conciseness of implementation logic: having chainable condition statements would hopefully lose a lot of if...else... conditionals within implementation logic 3) conciseness of conceptual mapping of the bound element to its name, eg. 'The "New Post" link" vs. "a#new-post" ...

Again, this is all just an argument from motivation rather than experience. It may turn out that this was a really, really bad idea.

I guess a follow on point is that unlike Hypertalk where the implementation is written in a DSL, whenever.js is just a way of _describing_ an implementation.

Everything else is plain javascript, and you can use whatever language features you want within the definition functions.

Someone knows if there is a relationship between this or BDD and a rule engine used by expert systems?

:(.

Using Whenever and Whenever (ruby cron gem) together will make my head pop.

If it's a painful as cucumber, I would stay far away.

This burns my eyes almost as badly as Fructose. Fructose, if you're not aware of it, is a C# application that translates Ruby to PHP. (http://www.fructoselang.org/)

There's a political complaint about the lack of semi colons in the script and its subsequent breakage in minification. Otherwise, I like it.

From a QA perspective, it's been my experience that no matter how much you simplify the DSL for the business user, it's always a pain to get them up and running and if you have a TDD point of view, you'll be much more successful, especially when engaging in a project that is very DOM-manipulation heavy.

_THIS_

It's hard to dumb it down enough for a non-technical user to do anything useful (in which case their tests are frequently invalid in a functional sense even though they're syntactically valid). But by that point you've usually dumbed it down far past the level a competent QA engineer should work at.

Happy to accept a pull request that adds semi-colons. I'm not particularly fussed!

sent

merged!

Thanks! I think the complainer will be silenced.

Reply on news.ycombinator.com