The BDD Next Level Checklist: 10 Things That Can Bring Your Web Dev Team to the NEXT LEVEL!

I've been a front-end developer for a while now. I developed single page applications with Flash and jQuery long before "SPA" was a phrase, and I now work mostly on modern JavaScript web apps. I've seen companies that are inefficient, have bad practices, and just flat out don't know what they're doing. With all the buzzwords surrounding software development and project management today as well new technologies popping up all the time it's easy to lose site of your main purpose as a team; to deliver features that generate business value, and to do it in a fashion that is efficient, controlled, automated, and accessible by the entire team. I've just recently finished reading the excellence book BDD in Action by John Ferguson Smart, and I'm incorporated his core principles into my development workflow (I'm trying to influence the thought leaders at my workplace to adopt these practices as well). In this post I've tried to boil down the essence of behavior driven development in the context of front-end JavaScript applications (just because that's what I know best. Most of these tips can be applied to virtually any stack). I thought TDD (test driven development) was the holy grail of software development, but BDD builds on those unit testing principles and truly takes automated testing, and the dev team doing the testing, to the next level. I've written each one in the "we" tense because you are supposed to think about whether your team is really doing this. Close your eyes and imaging being on a team that incorporates this practice. If you already do it, cross it off your list. If not, think about how much your organization could improve if that practice was implemented correctly. Be honest and say it out loud, "We don't do X", and then think about why not? Ok, enough suspense building. Let's get to the checklist! 

-----------------------------------------------------------------------------------------------

10. We Use Git (or some other version control system).

If you and your team members are not using git, you should be. What happens if your hard drive suddenly just crashes? What if a flood destroys your office building over the weekend? Is your whole project lost or is it saved in the cloud? And how would you even go about merging other people's files into the main branch without some type of version control system? With git can can roll back to a previous revision if you need to. It makes collaborating with others (or just working at multiple computers) much easier. Incredibly easy to get started with git today since you can play around for free with public repositories on Github, and there is a wealth of information and training on git, including this nice course from CodeSchool. Also, as we'll see later git hooks right into our continuous integration pipeline.

-----------------------------------------------------------------------------------------------

9. We Use a SPA Framework

Programmers often joke about [pre-ES2015] JavaScript since it lacks many things that are taken for granted in other languages like explicit data types and the concept of a class. Working in pure JavaScript is difficult because of browser inconsistencies and an unclear way to tie markup and JavaScript together, and many companies were having trouble successfully building large applications. Today, lot's of those companies are having success with SPA (Single Page Application) frameworks such Angular, React, and Ember. At it's core a good SPA framework should give you a flexible routing system and some form of "components" that provide a nice connection between the HTML markup and your JavaScript code. Although JavaScript gets a bad rep for having new frameworks that pop up all the time, these frameworks are seriously game changer and should be around for at least a year or two. hehe ;) 

-----------------------------------------------------------------------------------------------

8. We Use a Team Style Guide

Having a style guide is key because it keeps programmers all on the same page. In programming there are often times multiple ways to do the same thing. For a given project, being clear about how you are going to go about doing it will help prevent a ton of refactoring later. Things like directory structure, naming conventions for files, directories, variables, and methods are all to a degree open to the coder's preference, but having a company-wide style guide can help tremendously for employees that move across projects and codebases to have a clear understanding right from the beginning. At bare minimum you should study and adopt commonly held best practices for your particular platform or do a quick search for "[favorite JavaScript framework] style guide". 

-----------------------------------------------------------------------------------------------

7. We Develop With Hot Reload

For Front-End developers these days it's almost a given that you're going to have some type of task runner, and they all are capable of providing a hot reload feature. Whether you're using grunt, gulp, broccoli, webpack, angular cli, or something else there is usually a "serve" command that displays the site in a browser, and when any files changes it automatically updates the browser. This is super convenient and can drastically improve efficiency. And, not only can this file watcher be great for serving your site, but it can also be excellent for unit tests! Most task runners that can run unit tests also have a watch flag so that you can have the unit tests open in another command shell window and have them rerun automatically when any file changes.

-----------------------------------------------------------------------------------------------

6. We Have an Automated Build Process

As with the previous bullet, your task runner should have a command that is called something like, "build" that does all the minification, injection, moving files, etc. to prepare you webapp for deployment. There are a ton of different steps you can perform here so it's key to have this part automated. Minification of you code, images, and templates will ensure the fastest load times. It will do things like package up your dependencies and convert preprocessor languages like Sass or Jade as well. Also, having a command line build task will enable you to run it on you CI server...  

-----------------------------------------------------------------------------------------------

5. We Use Continuous Integration / Delivery

CI is really, really awesome when you have it set up correctly. Just push your code to git and it will automatically be put into the live environment for you to play with. It sounds like a dream, but actually it's real! Some people get bogged down with all the terminology around integration, delivery, deployment, etc. The key is that you want to think of it as a pipeline. Continuous integration hooks into git and adds functionality to it so that pushing your code is just the beginning of this pipeline. The CI server can grab your course code, run your build task, and push the dist/ folder to your hosting destination- all automatically immediately after every push to git master branch! And it's not just about automatically deploying your code, it's about checking to make sure there are no issues before it is deployed, too. This could be in the form of running unit tests, protractor tests, cucumber tests, smoke tests, performance tests, functional tests, etc. The point is that you can always be sure that the code that makes it to the end deployed environment has passed all the tests. If it breaks the build then it won't get deployed, and you can be notified of the issue.

-----------------------------------------------------------------------------------------------

4. We Have Dedicated Pair Programming Stations

This is actually a hotly debated topic. I am a huge believer in pair programming, and I believe that having a dedicated pair programming station is the only pure way to do it. Otherwise, you just have one person sitting at another person's desk, and it seems like the first person is slacking off. Pair programming is not a waste of time. Let me repeat that again. Pair programming is not a waste of time. In fact, I'd argue that "solo work" leads to more facebook scrolling, twitter creeping, email checking wasted time then when you are fully engaged with another human being. It doesn't have to be something that only happens when one programmer is stuck banging his head against the wall. Indeed, I've seen pair programming work best at the very beginning of the project where the technical manager / lead developer works with the other coders to lay the foundation of the webapp in a way that everyone understands it, is on the same page, and feels a sense of collective code ownership. This is the true power of pair programming. 

-----------------------------------------------------------------------------------------------

3. We Write and Trust Unit Tests and e2e Tests.

Nobody loves unit testing more than me, and it's really a shame how few developers engage in unit testing. Take the time to learn about unit testing and share your knowledge with more junior programmers. This is a way of bulletproofing your code and ensuring that when you're about to launch that you do, "know that you know that there's no bugs in the code". Unit testing is an automated way to check that a method works properly for all possible paths that it could take. E2e testing takes a somewhat different approach. Instead of being concerned with the methods of your code, it is more of "automating manual testing". They usually are written for Selenium (or something built on top of it like Protractor) and give a more wholistic confidence that everything works together. Also, these tests help check that your JavaScript code is correctly hooked up to the HTML markup. Together, unit testing and e2e testing provide the low-level specifications to ensure your app is solidly functioning as expected.

-----------------------------------------------------------------------------------------------

2. We Write Automated Tests in Gherkin.

I found out about Gherkin relatively late in the game. I had been writing unit tests and e2e tests since, after all, they are so great for ensuring software quality. However, I found my test being under-appreciated. Only I would ever read them or run them. The programmers didn't want to read through all my test code, and non-coder team members would have their planning materials in some other program that I would them have to translate into unit tests. The code was pristine, but the project was becoming an organizational mess with regrad to everyone knowing where we want to be, what we have done already, and what we need to do next. The Gherkin language revolutionized automated testing for me. It allows you to create automated tests that anyone on the team can (and should) read and understand. It makes you tests more business-value focused. It abstracts the high-level parts into a nice, readable form while giving programmers hooks to implement low-level unit tests behind the outward-facing Gherkin. It also free's the developers from having to keep telling everyone the status because it empowers everyone on the team with a living documentation...

-----------------------------------------------------------------------------------------------

1. We Have Living Documentation

Living documentation means documentation that is generated from the code. Any documentation that is not directly generated from the codebase will quickly become outdated, out of sync with the code, and eventually deemed unhelpful. Being able to generate a nicely formatted report of your Gherkin scenarios that details which are yet to be implemented, which are currently failing, and which ones are good to go is something that even the most senior programmers often don't have. Once you adopt Gherkin and think about your app in terms of features and scenarios, you may find that it fuses together the management and programming teams with a common, understandable language. Being able to show this collection of high-level specifications makes you a hero; it makes the non-programmers see you as the code messiah. Seriously! And when you have completed the project and moved on to your next big coding gig (maybe even at a different company) the reports are what live on. The nicely formatted and easily readable features / scenarios compilation is incredibly helpful to the "business as usual" team that takes over to maintain the application. It always puts a smile on my face when I see (or hear about) someone from these teams who looks at one of these reports for the first time because it blows their mind how much easier it is to take over and modify this project in comparison to every other one they've worked on. This is project management that works and works well. This is BDD at it's finest. So don't go to your next meeting with the CEO or CTO empty handed; go with your cucumber.js report! 

The automated tests generate json which can be viewed in any html interpretation of that json. I'm currently using this awesome github project cucumber-html-reporter. You can try a live demo here of the Bootstrap theme here. 

-----------------------------------------------------------------------------------------------

Follow Jim Lynch on Twitter @WebWhizJim 

and on Github @JimTheMan 

Also, feel free to join the discussion in our Linkedin group: BDD JavaScript