Pivotal Labs is a leader in Agile Software development, and it is wise to keep an eye on what they are doing. They are driving lots of good things in the industry – Jasmine being one, and also their Pivotal Tracker product being another.
'' == '0' // false
0 == '' // true
0 == '0' // true
false == 'false' // false
false == '0' // true
false == undefined // false
false == null // false
null == undefined // true
' \t\r\n ' == 0 // true
As can be seen by the above confusing evaluation of the equality operator- any language that produces evaluations such as this needs to have some tests backing it up.
Fear & Test Driven Development
Jasmine is an evolution in a rich and interesting history of Test Driven Development.
“Developers face complex programming challenges every day, yet they are not always readily prepared to determine the best solution. More often than not, such difficult projects generate a great deal of stress and bad code. To garner the strength and courage needed to surmount seemingly Herculean tasks, programmers should look to test-driven development (TDD), a proven set of techniques that encourage simple designs and test suites that inspire confidence.”
Frameworks like Jasmine helps us grow and understand the JS landscape with less fear using a testing language that reads well. Without tests, as applications grow, we may find “the fear” encroaching- fear from refactoring, fear of change; the exact place you don’t want to be as a developer. We want to be agile, fearless to make the right change to adapt and to sleep well at night. Instead of being the big lumbering truck slowing floating down the road weary of any sharp turns or adjustments to the road, we want to be on the little scooters zipping in and out of traffic. We dodge in and out of the traffic that constantly changes.
There are many good resources on the subject of TDD, but Beck’s Test Driven Development started things off and is still a great read as many of the main arguments haven’t changed. One of the key ideas is that in order to avoid fear of change and thus to be more agile, is to have automated systems that quickly let you know if the adjustments you make will break the existing software. As the size and complexity of the project grows, it becomes impossible to know all of the effects one will have when making changes. Complexity breeds fear, fear prevents you from being agile in a changing environment. Thus, systems that help you deal with complexity (a dependable battery of diagnostic unit-level tests) will help you be able to adapt to change. Your tests will tell if you should be afraid- afraid that you broke what was working before, otherwise have no fear everything is working just fine.
Evolving the Language of Tests
It is ironic that a common complaint of software engineers is that they aren’t good communicators and yet they are masters of many languages. The core of communication is language, and the core of software engineering is language- development languages. Languages are our tools and when we find ourselves in place where things can’t be done easily and clearly then our tools haven’t properly evolved. The most common ways to improve tools in this landscape is to augment existing languages and develop new ones.
Requirements and stories are captured in language as well. So we find a layering of languages that many people use to define and develop software. Unit Tests, as a language, are low-level and traditionally have been quite separate from the behavior-level language that is used in story descriptions. Behaviour-driven development or BDD is an evolution of TDD to try and find leverage by bridging the gap between the language of tests and the language of story descriptions. Less integration of languages (translation) later in the process is needed.
A proper resource on the topic, via is: The Cucumber Book: Behavior-Driven Development for Testers and Developers.