Showing posts with label BDD. Show all posts
Showing posts with label BDD. Show all posts

Thursday, September 3, 2015

Testing the Koa.js Response Context through koa-controller


Today I was test driving some new endpoints for my Node.js REST API.  I decide it was time to add koa-controller so that I could manage routes better and also map them to controller actions.

koa.js

I'm using koa.js for building out our new REST API in Node.js.

koa uses generator functions.  When you create a koa route, like anything, you can grab the request context and set the response context.

koa-controller

koa-controller adds in support for matching routes with controllers and actions.

A koa-controller receives the koa request context and then in your controller action, you can process the context.  And then set the context's response data, etc which koa uses to send back the http response.

With this middleware, I had created an initial action function as so in my controller:

(I apologize for shitty blogger and the lack of formatting below.  I'm working on moving this blog to some other platform)

module.exports = {
    find: function *(){
        var response = this;
        response.statusCode = 200;

        _gateway.find(function(foundData){
            if(!foundData || Object.keys(foundData).length === 0){
                response.body = null;
                response.statusCode = 204;
            }

            response.body = foundData;
        });
    }
};

problem is, how can my test get back the koa context to test whether my controller did what it was supposed to?  Right now, koa-controller passes back the context automatically.  But I wanna catch it for testing in my unit tests.

You can't just do a return response and we want to keep our functions async anyway and use callbacks (ideally promises) along with generators not because "it's cool"...but because it's necessary and also required by koa in the first place to be using generators for this.

Technically I should mock the koa context because I'm not testing koa; I wanna be testing  the logic I wrote in my controller only.  That'll be next.  But I wanted to figure out how I'd get the context back regardless first.

Generator Functions Save the Day

Since my action function has to be a generator function for koa-controller, that means I could use yield to return the context if I'd like.

That also meant making my callback function a generator or else this wasn't gonna work.

So here it is with yield and the callback generator function

module.exports = {
    find: function *(){
        var response = this;
        response.statusCode = 200;

        _gateway.find(function*(foundData){
            if(!foundData || Object.keys(foundData).length === 0){
                response.body = null;
                response.statusCode = 204;
            }

            response.body = foundData;

            yield Object.create(response);
        });
    }
};

notice I simply added * to _gateway.find's callback function.

Now you're probably wondering why I created another object here instead of just doing a yield response; 

Well koa-controller is handling returning the koa context so when I tried that, it was conflicting with koa-controller core code.  

So what I had to do is simply clone the context and return it.  Now it's independent of whatever process was handling the real context prior to this.

My Mocha.js Test

I use mocha.js for my BDD.

So now I can can test the context's values that came back from the controller's find action function:

it('should return no country when no country exists', function(done){
    var countries = {};
    countryMockGateway.setCountries(countries);
    countryController.gateway(countryMockGateway);

    var koaResponseContext = countryController.find().next().value;

    should.not.exist(koaResponseContext.body);
    koaResponseContext.statusCode.should.equal(204);
    done();
});

ES5

With ES5, you can easily clone which was very hard to do prior with simply Object.create().

So the next time your architect tells you "We don't need to be using new stuff like ES6, that's overboard", you can tell him he's full of garbage.  I didn't have an architect who did that where I"m working but I have in the past.  So here's a good use case for testing and using generators and cloning to easily accomplish what would have probably been a tangled mess of code to do the same thing prior to ES5.

Friday, May 22, 2015

Example User Stories with Gherkin - the start of the BDD process






First, I recommend you to read about BDD.  The point of this post is to show you variations in user stories that use Gherkin as the basis to name the feature and write the scenarios (Acceptance Criteria).

I do BDD on everything I code now.  It just works too well and makes too much sense because it guides you and also everyone understands what work is to be done, and what business requirements are expected of the developer.

Gherkin is usually written by product owners in Agile Stories.  And companies do do this, and they do like it a lot contrary to popular belief that nobody uses BDD, and PMs or business people won't do it.   That "won't do it" debate is when companies try to have the PMs or QA do the actual BDD code.  That's not what we're talking about here and that's not the right way to go about it.  No wonder there is so much confusion out there.  If you have QA doing your BDD code or PMs doing the BDD code, sorry to tell ya but your doing it all wrong and that's the source of frustration and the anti-BDD ranting posts out there.

What you do is you have your PMs or business owners write the Gherkin.  If for some reason you're doing something like I had to this week at work which is a few stories that just relate to my own setup environment, I write the Gherkin myself in some stories I just create for me.

I just wanted to share them, in hopes that it helps you understand how to start off doing BDD and how you can write good maintainable, and clear user stories for all.

For the stories that do require code for Gherkin, then developers will take the Gherkin and literally copy it right out of the user stories and into Cucumber.js features and scenarios for example...or whatever framework you're using.

Story #1 Setup Initial OS X Local Developer Environment on Laptop

(btw, the "feature" is the overall story itself, it's the title above)

As a new Software Engineer
I need to setup an initial basic local development environment for OS X
So that I can start coding SomeFramework, AnotherFramework, etc.
(scenarios might "seem" overkill for this but adding them anyway to explain requirements for creating a local environment for starters)
Acceptance Criteria
(minimal possible setup, the following tests that we have things "working")
Scenario: Able to Run a NodeJS app
Given I have installed NodeJS
When In my favorite Code Editor (e.g. Webstorm)
Then I should be able to spin up a new Node app
Scenario: Able to Run ExpressJS and a web app
Given I have installed NodeJS and Express installed
When In my favorite Code Editor (e.g. Webstorm)
Then I should be able to run a website locally
Scenario: Able to Run Cucumber.js BDD Tests
Given I have installed NodeJS and Cucumber.js
When In my favorite Code Editor (e.g. Webstorm)
Then I should be able to create 1 BDD test (see the test fail (red) then make it pass (green))
Scenario: Able to Run Mocha TDD Tests
Given I have installed NodeJS and Mocha.js
When In my favorite Code Editor (e.g. Webstorm)
Then I should be able to create 1 TDD test (see the test fail (red), then make it pass (green))

As you can see, everything is very clear.  It's a no brainer, Gherkin is a great way to communicate all this; it makes sure it's short, and everyone will be happy, and it's something developers can run with and know they're doing what they're supposed to be doing.  And it also then guides us and truly gives us a precise starting point in our BDD code.  And we need this because the BDD code guides us down to the very first TDD tests we'll do in order to implement (complete) this story before passing it to QA for final integration tests & closure.

Here is another example


In this case, I don't really have scenarios or need any for this, so I just write the feature and that's it:

Story #2 Basic Documentation of OS X Local Development Environment Setup

As a new Software Engineer

I believe it would be helpful along the way to be document the setup
So that myself or anyone new or existing could get up to speed, learn, or save some time possibly
Note: Maybe some of it would be helpful in the future also if we ever created an OS X developer image for laptops?


And here is a story where I'll be spiking some code and later scrapping the code.


It'll only be used for some short-term temporary testing with some new automation tools we're proofing out...so since I'm spiking then will literally remove the code later on in our source control, there's no need to be doing BDD or TDD here...we do not plan to use it as a base for any code or use it in production:
(note that the italics below are to replace real words as to keep this generic for public viewing purposes)
Story #3 Simple NodeJS Web App Rendering Static Content
Feature: Simple NodeJS Web App Rendering Static Content
As an admin of SomeAutomationSystem
I want to have available a very lean NodeJS app running static content
So that the team can work on figuring out how to take that code and DoSomethingWithIt in SomeAutomationSystem 
Acceptance Criteria
Scenario: Web Page loads and shows static content
Given I run the NodeJS web application in the browser
When The page is done loading
Then I should see the the content "This is a Web Page Running on Node and Express"

So you can see how User Stories (features) coincides with BDD and how the Gherkin syntax is IMO the best way to be writing stories not only because it's clear, consistent, and concise, but because devs can straight up copy and start working with them in whatever BDD framework they are using that uses Gherkin, usually it's Cucumber.  I am using Cucumber.js.

Wednesday, April 1, 2015

Do You Need Cucumber or even BDD?





Do You Need BDD or Cucumber?

This is a debate that has been ongoing for a while in the development world.   

The crux of the arguments out there are have been:

  • "BDD is a lot of overhead", meaning writing the tests slows us down
  • "You don't need BDD, it's a waste of time"
  • "Business people don't care about technical Parts of BDD or writing the tests" so "They never write them so BDD is pointless"
I'm sure you've read or heard those arguments time and time again, I know I have.

I do not claim to be a master in BDD however I'm getting to the point to where I'm doing it enough to where I'm able to draw the lines and see those arguments start to shrink more and more.

Proof

You want Proof you say! Well you got it.

For this blog post I'm focused on a recent conversation I had with a close friend who is seasoned at BDD and TDD.  I passed him this argument by Kevin Liddle because I'm truly interested in working more with BDD daily, and want different opinions out there period.

He disagrees with some arguments out there against BDD as well as Cucumber.  Because in his organization it has only been a great tool and helps their organization and has seen much success with Cucumber.js.  He is running several large development teams right now in his organization (all of which are doing BDD and disciplined TDD) and has been promoted to drive his process down to and lead rest of the organization because it's worked so well for the company overall.

He has found success with BDD and specifically Cucumber.js in his organization all the way from the non-technical business stakeholders all the way down to acceptance of BDD from his own developers across all the teams he manages.

His organization isn't some start-up, it's big.  And things have to work well.  They're driving the next wave in fact and leading their industry in terms of the awesomeness coming out and competitors are taking notice and actually using their APIs as a result!  What more testamony to design, BDD, and TDD can one get.  This is real tangible stuff at a large organization with a lot of devs.  And if anything could put DHH's baseless argument against TDD to rest, this would be a great example.

The following is a summary of our interesting conversation and sheds some light on one good sized organization and their dev teams who have seen huge value in Gherkin, Cucumber, and BDD.

Remember the ".js" after Cucumber because it's significant as you will read further below.


"BDD is a Waste of Time!"

First, this is nonsense.

If you haven't seen the value yet, then most likely one of these reasons:

a) Have you tried to or are you actually coding BDD yet? 

If you've only read about it then then why make uninformed biased conclusions if you've never experienced it yourself right?

b) You've done some BDD but did it in an organization which has made a mess of it.  

Well then of course you might view it that way

c) Maybe your organization isn't going about it in a lean or clean way:
  • Cutting out QA completely from the equation
  • Maybe you're tests themselves are written poorly such as including implementation details in the Gherkin which should not be there.  BDD is for high level functional requirements, not the how to implement them
  • You're still using older framework that make it hell to maintain those kinds of tests and running them are slow because of that framework

For me, BDD Makes Sense and is Valuable Without Question

I've been doing some Cucumber.js for my own personal projects lately and it just makes complete sense.  BDD tests are a perfect starting point from Agile Story to starting the actual related code for that story.   Watch this video from Corey Haines, he shows you nicely how to start a new project both from a Business Domain / Priority List perspective right down into starting your first BDD tests, and then implementing the code via TDD.

BDD tests guide you.  I honestly can't think of not doing them anymore after having done some in Cucumber.js.  Because they force you to think about the business requirement at the highest level first.  It's a better starting point than taking some garble that varies from Story to Story and assuming you're getting off to the right start with just diving into your TDD tests.  Everything is clear when based off Gherkin and verifiable.

BDD tests drive the lower-level implementation.  That is they determine the direction and scope of your TDD tests once you're ready to implement the real code.  BDD forces you to think about what scenarios you need to think about first, as lean as possible, and at a high level.  And then that reduces the scope of your unit tests making the correlation of TDD tests to BDD tests a tight nit family.

A Proven Process

First off if you are trying to BDD in your organization and you're expecting Stakeholders, PMs, or QA to write any amount of code is a ridiculous expectation that shouldn't be in your organization in the first place and you are going about BDD completely wrong.  And that goes for QA too!  They shouldn't be writing BDD...period.

Business Stakeholders could give a crap about code.  They care about getting requirements right and seeing those being built succesfully and with high quality form the development team.

My friend told me BDD has only helped.  In no way is it debated in his organization, because it's produced results.  Proof first-hand in a large organization.  Because they do it right.

Quotes from my friend from our discussion

"You have to keep things in perspective.  We're talking about it in the context of Cucumber.js with Node.js, not older Cucumber frameworks.  Cucumber.js and older Cucumber are not the same in terms of speed to code and run those tests.  So the speed argument doesn't apply to what we do here.


As for the argument that business people won't write Gherkin or that Gherkin is a waste of time isn't true for our case.  

That's because all our business people have agreed as a standard to write acceptance criteria in Gherkin format right into their Jira Stories and we don't ask them to do anything other than that, that's where it stops.  That's not difficult for them to do, and they like it!  We don't expect them to write any code.  In fact we don't even really have QA anymore, we've trimmed QA out of testing completely and have very few QA resources period.

Our Engineers then simply take and copy the scenarios that are in Gherkin format from those Jira stories that were written by the non-technical managers and PMs, and and write a BDD test for them and it's not a big deal to any of our developers.

And Since it's fast to write tests and setup Cucumber.js over Node.js, there's not a problem with it being slow to run or code at all...so this is not the same as using older Cucumber to do this and so it's not a problem for our business or devs and it works great for everyone here.

Our team has been doing it for a while and don't complain about it…they actually like doing it.   Where teams start bitching and stuff is a dirty little secret.  It's usually those teams who have QA staff.  And the QA staff is essentially doing half of their testing for them.  Once you remove the QA staff from the equation then it's different.  

You tell the engineers they're responsible for the quality…then all of a sudden that automation makes a lot more sense to those engineers.  So that's the piece you are not seeing in those arguments also…is that most of these engineers tend to have QA resources as part of your team and is why BDD is getting a bad rep.

We then run our versioned automated functional tests (Cucumber.js BDD test suites) every 30 minutes against all our environments all the way up to production on our apps all the time."

That's what Gherkin is For
Given I am a user
When I go to the main landing page
And I see that there are some events scheduled for Metallica
If you think about it, how many times are you in an iteration planning meeting and you're trying to write some of the acceptance criteria and your description and details around that varies greatly in who wrote it in terms of how it's written...it's usually a big mess with no structure.  In Story A someone wrote it in a nice clear concise manor.  Fine.  In Story B for the same product, same iteration wrote too much, or wrote it messy because they have a language barrier, or just don't give a damn or just are not very good at writing to begin with.  That happens, because we are all different, we're all human.

But when you have your business stakeholders write the criteria all in Gherkin right in your story it just make complete sense.  That's the whole value of Gherkin to begin with.  A template to write clear and concise functional requirements anyone can understand and think out in a consistent and very clear manor.  

So stop having different people use different templates (or no template! even worse) for writing the acceptance criteria in your user stories.  Just use Gherkin style.  It's just too easy and it makes too much sense not to.  Be consistent.  Be clear.


Developers Take Gherkin and Write The BDD Tests Themselves, not QA

Yes I said Developers...not QA, nobody else.

No this is not far fetched and no this doesn't slow down the team.

Your developers (not QA!) simply and literally copy that Gherkin typed by your business owners from the stories and when they start on implementing a story, first they they do is create the Cucumber.js BDD tests starting with the Gherkin themselves and don't even question or complain about doing so because it just works.  

You start with the Gherkin written in whatever Agile Software you're using to create Stories, have the business people write that gerkin as acceptance criteria in the stories, then have engineers take that Gherkin and write the BDD tests.  After you have your BDD tests written, they serve as a guide in the next step which is to start writing the TDD to implement the real code for those BDD scenarios.  It's very much a controlled, clean, and fast way to get things done.  It's a lean way of coding and getting shit done.  

There's no going to QA or having an expectation for anyone but the developers to start implementing the rest that's under that BDD.

Cutting QA Out, Are you Joking?  You Jerk!

This is not a new concept.

It's not theory or wishful thinking for some organizations.  It's actually really being done more and more across organizations today as they embrace more Pair Programming coupled with TDD and figure out how to make BDD work.

When BDD is working right and is working for non-technical owners, that's where things start to change.

It's because some organizations utilizing BDD have gotten to a certain point to where their BDD process is driving things and working for all involved and that when oupled with TDD and simple design, everyone starts to see a very low bug count and even rare corner cases aren't there much anymore on all apps being developed or new features added or changed.  So you end up literally not needing to have that extra layer of a QA department bogging you down.  It's straight up business owners to devs.  The Business owners know what needs to be done to meet a requirement for the business and it's getting done by the developers effectively.

Developers code the BDD for the Gherkin, and develop the code via TDD.  There's really not much more to do and really not much need for much if any QA after that when everything is aligning this well in an organization.

Obviously Can Also Use Other Frameworks

I'm not completely biased toward Cucumber although my wordage might indicate that in this post.

Note that there are other test frameworks such as Mocha.js where you can kinda do the BDD and TDD all in one roof.  Currently I'm trying to use Mocha.js for the TDD tests and Cucumber for the BDD on my projects.

But I'd still see some value in using Gherkin-like wording in Agile Story acceptance criteria.  And then implementing the code for that by devs.  You could use other frameworks outside Cucumber is my point.  It's just that by adding the Gherkin-like wording is still valuable, clear, and maintainable at the story level when written in your Agile Stories during iteration planning.

Conclusion

I think the most important points coming out of our conversation were the following:

1)  Just have your stakeholders or PMs write the Gherkin syntax in the Agile Stories as the Acceptance Criteria, no coding required

2) Devs should be picking up the Gherkin from those stories and writing the BDD tests themselves, not QA

3) It's been proven to be a very Lean way of producing code and satisfying business requirements

4) Cucumber.js and Node.js changes the ballgame on the old argument of Cucumber is slow or time consuming for devs

5) The teams who have QA doing the BDD tests are actually putting up a wall to getting the actual work done and tested

6) QA is being removed from the equation more and more entirely, because bugs are low when BDD and TDD work well and you have clean, testable, and maintainable code as a result of that and keeping things simple / minimal / lean


Be Careful


So be careful of the general arguments out there against BDD in terms of if you need it or not.  And in my particular conversation, revolving around Cucumber.

Things are changing in both the BDD framework scene these days, and how BDD is being done.

Arguments that have existed against BDD and against Cucumber in this case are becoming stale and no longer true in some organizations.