Showing posts with label Behavior-Driven Testing. Show all posts
Showing posts with label Behavior-Driven Testing. Show all posts

Wednesday, October 30, 2013

Quick Point on Cucumber

Quick point on Cucumber

Last night we covered the next two chapters of The Cucumber book. These were on Gherkin -- the syntax for specifying Scenarios. It's kind of amazing that the keywords are essentially meaningless! You can actually use an "*" in place of any keywords, with exactly the same results.

We also determined one reason why "the enemy" disliked it. There is no namespace capability within Cucumber. Consequently, it becomes cumbersome proportionally with the increase in Scenarios and Features. At least it throws an error if an ambiguous step definition is created. But as the number of scenarios increases, the time necessary to run also increases.  Which is to say, it doesn't scale well.

Next week -- on Tuesday,  will be the LAJUG main meeting & I hope to see everyone there!

Also next week -- on Monday, will be the Technology Radar Group & I hope to see everyone there as well. :-)

I Remain,


Wednesday, October 23, 2013

Cucumber Word salad

Great attendance & surprises indeed last night at the GeekBookClub, more properly called the LAJUG Study Group.

We began the new book: The Cucumber Book, seen above.

It's a bit Ruby-esque, but applicable to Java via the download of cucumber-jvm, which I'll need to investigate.

So, I got my MacBookProRetina loaded up with Ruby as a prerequisite for the Cucumber install, and followed the appendix without serious issue to get a working cucumber installation up to try things out. And I entered the first bits of chapter two's "First Taste," and got the same results.

Apparently, the whole Cucumber/BDD -- or Behavior Driven Development -- is based around attempting to provide a communication tool that can involve business people as well as developers in producing executable specifications.

To begin with Cucumber is a command line tool.

That's cool, to the inner Hacker that constitutes TheHackerCIO, because GUIs are for those who can't Hack. Your mileage may vary.


There is a sort of word salad of technical terms in the cucumber suite, so here is a quick glossary ...

feature is  a flat file that contains plain-text, ordinary language descriptions of one or more scenarios.

A scenario is a list of steps for Cucumber to work through. These scenarios must follow a particular syntax so that Cucumber can work through them.

Gherkin is the name for the syntactical rules required of the scenarios. Gherkin uses keywords such as Feature, Scenario, Given, When, and Then to provide the needed structure to the DSL.

The steps, or step-definitions are where Ruby programs actually get bound to the specification, thus making them executable.

The essential point of all this is to make it possible for business -- that it, non-technical -- people to get involved in writing acceptance tests. That seems like a good thing.

The big surprise in last nights discussion was in one new, first-time attendee. Newcomers are freely and warmly welcomed at our book club; at whatever level and from whatever technology background. And this newcomer was already very familiar with both Ruby and Cucumber!

So, instead of a discussion among people all eager to learn a new technology, we had an interaction with someone who already new and HATED the technology! That was a twist! This person was coming to try to see whether she could be convinced of the value of Cucumber from the Pragmatic Programmer book!

We spent quite a bit of time trying to understand what her issue was with the tool, and we all quite happily viewed a demo of how Cucumber works, which she whipped up for us on her Macbook and ran.

Seeing a live demo on the spot certainly made it a lot easier to grasp the whole essence of Cucumber. It's amazing how much superior a tutorial is to reading, no matter how much I like reading.

So, you'll have to stay tuned for future blog postings to see what we learn about Cucumber and whether it's useful or a pain! No matter what the verdict is, new technology needs to be learned about and evaluated. And so ...

I Remain, Ever Learning, and ...


Wednesday, September 25, 2013

Cucumber Gets It's Day

So the next book to be read by all my co-Geeks is the Cucumber book pictured above, followed by the Data & Reality book.

These are choosen democratically by a vote of ATTENDING members. The vote took place last night, and Cucumber was the winner. I know very little about Cucumber, except that it purports to be a behavior-driven approach to testing and development.  I wasn't too happy to learn that I'm going to have to mess around with Javascript for the Cucumber book!

For those who don't know, Java is to Javascript as Ham is to Hamster. Javascript isn't type-safe. It's loosy-goosy typed, which means that data types can be created willy-nilly from whatever data they contain into whatever type you need for something else. That sounds nice, and might even speed up prototyping. But for writing a stable production system, the errors that get lost in the mix are very troubling. Especially when they bite you in production! Java, by contrast is strongly typed. All errors are gotten up front. For those of us who like strong-typing, we'd like all our errors caught up front, thank you very much. We'd just as soon not find them later, in production. At 9:30pm on a Saturday night. You get the picture.

The book is now on it's way to TheHackerCIO from Amazon and I'll be posting about it in the future. Most likely on  Wednesdays. And after Cucumber, the runner-up was Data & Reality, which will be the next book for Geeky discussion.

Actually, the other books looked pretty good as well, and so I bought the lot! That's the problem with loving technology! Seriously, they all looked good to me. The books that didn't make the grade were:

Behind Closed Doors, not to be confused with Behind Closed Doors, as I did on my first Amazon search!
Cryptography Engineering
Agile Database Techniques

  On the Java Performance book, the discussion of the day was rather light. One of the great things about this particular club is that the side discussions make up for the deficiencies of the books. We'll come back to that in a moment. Last nights' chapter was on Web Services performance.

Many comments were raised about exotic JVM options. You can disable explicit GC calls with a startup-option. That's kind of weird, since you can't depend on GC happening from an explicit call anyway, so this is a very exotic option! GC, BTW, stands for Garbage Collection. It's one of the cool features of Java. In the bad old days of C and C++,  you had to manage the memory you used in your programs yourself. Since everyone screwed this up, lot's of "leaks" of memory resulted. Consequently, when you run an application too long, and enough memory leaks, your whole system freezes up, or "hangs." Now you know why. Java helps in the regard, by simplifying memory management.

I wanted to know what a NUMA architecture was, referenced in the book. NUMA stands for Non Uniform Memory Architecture. I apparently wasn't the only one unfamiliar with it. When I said to the group I'd like to know what it was they referred me to Google! I'll forgive them for it. At least this time.

Next we discussed and reflected with surprise on the section where it was pointed out that XML processors are NOT thread-safe! "JAXP does not mandate that factory instances be thread safe." One of our participants told how he learned this the hard way, from getting a ConcurrentModificationException. He couldn't reproduce it, but synchronizing the method resolved the exception.

We all disagreed with the book about the importance of XML. As far as we're concerned it's deprecated, and well deservedly, along with SOAP. Everything from now on ought to be REST and JSON. By the way, I really, really would appreciate some colleagues visiting my LinkedIn profile, found here, and endorsing me for REST. I only have two endorsements, and it's so low on the list. Yet I did the whole book club discussion about REST. At least you guys should endorse me for it.

So, this blog posting is getting long, but the book club members primarily like todays posting.

The side-bar discussion that was really interesting and tantalizing was a teaser about Resource Oriented Computing and the company Netkernel. Apparently, this approach is a complete paradigm change, according to our participant. He's researching it, and planning to implement ESIs (Edge Server Includes) as a first step, which have something to do with optimization of the CDN (Content Delivery Network). With any luck, we'll get a presentation from Earl on this!

I Remain,