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.

Installing & Using Chocolatey Package Manager for Windows

I'm very used to using tools like npm to install node modules in an OS X bash environment.  Or tools like Homebrew + Cask as well, I use both ways.

Windows sorta has a Homebrew'ish like that called Chocolatey which is a Nuget based package manager via command-line that attempts to mimic something like the popular Homebrew in OS X.

With package managers you can do all sorts of cool things such as install stuff in 2 seconds rather than go out to the net for executables.  For example one can do this to install a bunch of common programs you might use in your development environment:

choco install google-chrome-x64

choco install firefox

choco install git.install

choco install atom

choco install 7zip

choco install ccleaner

choco install node.js

choco install filezilla

choco install fiddler

choco install virtualbox

choco install pdfcreator

choco install windirstat

choco install itunes

and because you're using a package manager and its commands, that means you can automate creating your development environment too by creating a chocolately script or HomeBrew script or whatever.  

Imagine creating a script that you could run on a fresh install of windows that does a bunch of chocolatey commands (or equiv of Homebrew in OS X) to install and setup your entire local dev environment.  Sure would save a hell of a lot of time.  Especially if you haven't imaged your laptop the last time you went through the pain of setting up our dev environment manually.  When i say manually, meaning do the typical go to the web, go to FireFox, Google, and other sites to manually click all over and download and then run the exe, stupid wizards, all that.  You can bypass a lot of that hassle and save time by creating scripts along with using Chocolatey or HomeBrew and automate most of the things you use as a developer.

I use Powershell for all that I do.  So I'll use PowerShell to install Chocolatey.  You can also just use the command prompt but why not just use PowerShell is my argument.

Here is how to install it

    There are a couple little pain points that you need to be aware of if you haven't used PowerShell and such while trying to install Chocolatey that you'll come across.

1. First, make sure you elevate privileges with PowerShell to allow the Chocolately script to be run on your comptuer

  Run the command Set-ExecutionPolicy RemoteSigned

    2.  Install Chocolatey
         Run the command: 
           ex ((new-objec net.webclient).DownloadString('https://chocolatey.org/install.ps1'))

3.   Start using it

      Here I'm installing Git for Windows with a simple Chocolatey command:

So simple.  Now it's installed.  Note that there are many Git packages up on the Chocolatey website.  This one installs Git and then you can start making Git commands right from PowerShell thereafter:

This is not installing something like Mysis Git Bash prompt.  If you want something like MysisGit, if there isn't a package that does that for you in the Chocolatey Packages directory listing then you'd have to go manually install it yourself.

You can also quickly install stuff like Chrome which will do everything you expect..pulls down the Chrome executable runs it and installs it for you without you needing to do a thing.  All you have to do is type choco install google-chrome-x64

This just scratches the surface.  Windows 10 is coming out with their own built-in Package Manager finally.  We'll see if it's any good.

Setting up VideoJS with Intrinsic Ratios

I use VideoJS for DimeCasts.net.  It's been a proven HTML5 player that is used by Google, funnyOrDie.com, and many other well known websites.

I realized for some reason that VideoJS was not being responsive on DimeCasts.net lately.  What I mean is if you make your browser larger or smaller, the video player should re-sample its size to fit that new browser size and still maintain an aspect ratio that fits into the container in which the video player sits.

I'm almost finished doing a re-code of the views using bootstrap.  Originally DimeCasts.net which was started in 2008 was designed via rigid table driven layout.  I'm finally getting rid of this after taking over DimeCasts last year.

However even when I have the viewsre-coded and using Bootstrap, I found that VideoJS still wasn't re-sizing on browser size changes.  

A quick search brought me to this post.  

So all I did to get it intrinsic is to then just add that padding to the containing dive around the video component and the video player is now responsive (changes dimensions to fit the container) when you enlarge or decrease your browser window.

I also changed the width and height of VideoJS to 100%, and surrounded everything with a paragraph tag.

For example:

.makeVideoIntrinsic
{
        padding-bottom: 20%;
height: 0px;
}
            <p>
                <div class="media-body makeVideoIntrinsic">
                        <video id="<%=ViewData.Model.EpisodeName%>" class="video-js vjs-default-skin"
                            controls preload="auto" width="100%" height="100%"
                            poster="../../images/CastThumb_Large.png"
                            data-setup='{"autoplay": false, "preload": "auto"}'>
                            <source src=<% = ViewData.Model.FileName %> type='video/mp4' />
                        </video> 
                </div>
            <p>

I'm happy to say that the new Bootstrapped DimeCasts.net update will be out soon.