book

Test-Driven JavaScript Development

by Ravi Kumar Gupta

December 2015

Intermediate to advanced

240 pages

4h 57m

English

Packt Publishing

Read now

Unlock full access

Support files, eBooks, discount offers, and moreWhy subscribe?Free access for Packt account holders
What this book covers

Downloading the example codeErrataPiracyQuestions
Complexity of web pages
The need for testingTypes of testingThe life cycle of TDDTDD microcycle
BenefitsMyths
Unit testingUnit testing frameworksYUI TestsFollowing the processPreparing the environmentFollowing the life cycleWriting a testRunning the test and seeing if test failsWriting a production codeRunning all testsCleaning up the codeRepeatUsing the browser consolesetUp() and tearDown()Test suitesActions and assertionsActionsAssertions
Benefits of unit testingPitfalls of unit testing
JsUnitGetting startedWriting testsRunning tests
Getting startedWriting testsRunning tests
Getting startedWriting testsRunning tests
Getting startedWriting testsActionsAssertionsRunning tests
Understanding behavior-driven development
Tracking spies using callsCreating a custom spy
Asynchronous callsThe Jasmine Ajax plugin
Disabling suites and specs
JsTestDriverOverviewGetting startedWriting testsAssertionsCapturing the browserRestructuring your projectThe configuration fileRunning tests using the command prompt
Running the testsRunning Jasmine specs
Understanding feature detectionAvailable methods and libraries
Writing custom tests
Downloading and setting up ModernizrHow it worksUsing ModernizrPolyfillsLoading polyfillsSupported browsers
User agent sniffingObject detection
CSS featuresHTML5 featuresMiscellaneous featuresPlugins for additional tests
Modernizr.prefixed()Modernizr.prefixedCSS()Modernizr.mq()Modernizr.on()Modernizr.atRule()Modernizr.addTest()Modernizr.testStyles()Modernizr.testProp()Modernizr.testAllProps()Modernizr.hasEvent()Modernizr._prefixes and Modernizr._domPrefixes
Overview
Event dispatcher/listenerPublish/subscribePush versus pullSample codeUnderstanding patterns in APIThe notify methodSubscribeUnsubscribe
Red step (code with error)Green step (with running code)RefactoringHot swapping componentsBrowser compatibility of the observer API
Setting up the environmentInstalling Node.jsSetting up the applicationChoosing a test runnerMocha and Chai
Implementing the web serverHelpdesk – sample applicationSetting up the MongoDB databaseThe Mocha test
TDD best practices
Make test case names more readableKeep the same name for test files and source filesKeep the name descriptive
Making sure that tests are written before starting implementationModifying/writing new code only when the test is failingRunning all the tests when we modify anything in the existing codeExisting tests should pass before new tests are writtenCleaning up code once all test cases are passed
Simple code that can be easily understoodWriting assertions firstOne assertion per test is enoughKeep your focus on findabilityReducing duplicationTests should run fastUsing mocksUsing stubsUsing setUp and tearDown methods
Feature detection toolsServer-side testing toolsAsynchronous testingRunning time of unit testsBrowser supportOther featuresJsLint

Content preview from Test-Driven JavaScript Development

Follow proper rules to define test cases

Properly defined test cases gives a better view of the code, and developers can easily find what they want to find in the code. Many tools also need proper naming conventions to be followed. There are so many naming conventions techniques available out of which we will see a few techniques. It is better to follow some naming conventions than nothing, like the saying "something is better than nothing."

Let's take an example of a project. If it is mandatory for all users to follow the same naming conventions, everyone will have to follow the same standard. When it comes to module integration or to understand the code written by other developers, it's easier to follow the flow of system.