
What if cucumber and jQuery had a baby? - tswicegood
https://github.com/paulca/whenever.js
======
3am
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).

~~~
kragen
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.

~~~
3am
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.

------
paulca
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.

------
seliopou
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.

~~~
paulca
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!

~~~
seliopou
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);

~~~
paulca
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:

<a href="#" data-bind="posts#new">New Post</a>

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.

------
blhack
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"?

~~~
sneak
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.

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

------
asnyder
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".

~~~
paulca
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.

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

------
hitonagashi
:(.

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

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

------
MostAwesomeDude
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/>)

------
jsavimbi
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.

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

~~~
aaronblohowiak
sent

~~~
paulca
merged!

