A practical guide to Full Stack Test Driven Development (TDD) for people building robust node.js and web / mobile applications in teams!
We build web apps to:
- share information
- connect & communicate with our friends, colleagues & communities
- buy/sell things
- run organisations/businesses
- manage all aspects of our lives (calendars, task/time trackers etc)
- have fun (online games!)
We think it make sense for these apps to be reliable. Do you agree?
Reliability is achieved by testing.
A "stack" is the term use to describe all the components involved in a web app. The more comprehensive definition is:
"In computing, a solution stack is a set of software subsystems or components needed to create a complete platform such that no additional software is needed to support applications. Applications are said to "run on" or "run on top of" the resulting platform.
... in a web application the architect defines the stack as the target operating system, web server, database, and programming language."
A Typical Stack would include:
- Linux/Unix as the Server Operating System (OS)
- a web application framework running on the server. Example frameworks include:
- Ruby-on-Rails/Sinatra (Ruby),
- Django (Python),
- CodeIgniter/Symphony/Drupal (PHP),
- akka (Scala/Java),
- Express.js/Meteor.js/Hapi.js (JavaScript/Node.js), etc.
- the (web app) framework connects to a database. There are many databases (often referred to as "data stores"), the most popular are:
- SQL-Based: MySQL, PostgreSQL, MariaDB
- NoSQL: MongoDB, CouchDB, HBase, etc
- Search: ElasticSearch
- Key Value Store: Redis, LevelDB
- Browser-based interactivity (often referred to as the "Client" or "Front End" of the stack).
The term "Full Stack" Developer has been around for a while. We like @laurencegellert's explanation:
"a Full Stack Developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology."
We agree with @peteryared that it's naive to expect anyone to be an "expert" in ever aspect of our stack, but we do think that by using JavaScript as the (programming) language for Server (Node.js), Client (take your pick of framework!) and Datastore (any of the NoSQL datastores which store JSON documents).
See: http://techcrunch.com/2014/11/08/the-rise-and-fall-of-the-full-stack-developer/
In web development, there is one language that all web browsers understand: JavaScript
The web browser or mobile device (displaying content in a "web view") is referred to as the "*Front End"
### "Back End"?
When people refer to the "Back End" of an app they are describing the "Server" component(s).
There are many technologies/languages/frameworks you can use to write your server. As stated above, for simplicity we prefer to use JavaScript (Node.js) on the server to keep one programming language across the stack and allow us to re-use view code for both server-side and client-side rendering.
Writing tests for all aspects of your application.
Some people have a natural aversion to the idea of testing because the word reminds them having to do exams in formal education (especially those of us who suffered from the experience!)
Don't Panic! Writing tests for your Web Application is on the opposite end of the Fun Spectrum from multiple choice tests we all know (and hate!)
There are a number of "reasons" (excuses!) why people/teams/organisations still don't test their work.
Take your pick from the following:
- "We don't have time to write tests, we just need to get this done Yesterday!"
- "Testing takes too long and means we won't deliver as many features..."
- "Its just a small fix, we don't need to write a test..."
- "I'm a developer, I don't write tests, we need to hire a tester..."
- "If I write a test for every bit of code, then I have to update the tests when I need to change the code, so it's twice as much work..."
and, last but not least:
- "That's the way we have always done it here..."
As a comparison, this is how we used to do Mobile Phones ... How many people do you still see carrying "The Matrix Phone" (which was all-the-rage in the 90's!) today?
We have better phones; shouldn't we also have better software development methods?
We have all met a Cowboy Coder ... The "I just get things done" developer who writes "quick fixes" and exclaims: "I don't have time to write tests" or "Writing tests for my code takes longer" and then acts surprised when everything starts breaking while claiming: "it was working this morning" ... Please share this with them and help them see the light!
Code without tests is like a building without a foundation!
Its only a matter of time before it all comes crashing down ...
Q: Is Test Driven Development (TDD) a silver bullet for all my software development woes?
A: No.
There is a lot more that goes into writing great software than
just having tests. But, without tests reliability is impossible.
The days of poor quality software are numbered; people who continue to expect inconsistent results to be rewarded are in for a "surprise"!
This book is our effort to accelerate the process towards ending un-tested software! We invite you to be part of the TQM Software movement and bring all your friends/colleagues!
The Book on Web Application Testing is being written one-page-per-day and published at:
The answer is: it depends. If you can handle a few typos and want to get started building better software ASAP, then start now! If you prefer to wait till its "ready", please star the repo, register your interest at: https://leanpub.com/practical-js-tdd
click on the image to re-tweet! (thanks!)
Each day for the next 4 months I will be writing at least 1 page and pushing it to GitHub (which triggers the book publish script on LeanPub) so there will be fresh content every day! I promise to make every effort to keep the signal-to-noise ratio as good as possible!
We hope this will be a (highly) collaborative effort! (We don't believe in "lone wolf" or "basement genius" approach to building things... we prefer the many minds/eyes/ideas Open Source culture!)
If you want to contribute you can get started by reading the files in the /manuscript directory. They are ordered numerically by chapter. e.g: manuscript/01-intro-why.md gives the top 7 reasons why people should be testing their work.
If you have any ideas, comments or suggestions, please raise and issue on GitHub: https://github.com/nelsonic/practical-js-tdd/issues
If you want to receive ALL the updates, you can Watch this GitHub repo. note: you may get quite a few emails... but if you are interested in building great quality software, the content should be relevant to you.
Yes, the book is 100% Open Source on GitHub for anyone to read and contribute to! We (strongly) believe that Education should be open and freely available to all!
I was lucky enough to be named after this guy!! (Thanks Mom!)
Yes, the book is (and will always be!) 100% Open Source, but LeanPub is kindly providing a way of "packaging" it up for people to read on their devices in the form of a (DRM-FREE) PDF (readable on any device) Mobi (for our friends with kindle) and EPUB (for iDevices and Macs with iBooks) they have infrastructure to pay for, so I think its fair to pay a fee for the service they provide ...
ALL the proceeds (after LeanPub fees) from the sale of this book will go into the #dwyl fund for the South African Technology School we plan to build in 2016 in our quest to create (well-paid +remote) Tech Jobs in Africa!
If after watching this video you aren't inspired to get involved, please let us know what does make you tick and we can donate the proceeds of your copy of the book to a different charity.
If you are a student and/or low on cash (we've all been there!) but still want to learn how to build great quality software, please personal-message me