Book Image

Building Enterprise JavaScript Applications

By : Daniel Li
Book Image

Building Enterprise JavaScript Applications

By: Daniel Li

Overview of this book

With the over-abundance of tools in the JavaScript ecosystem, it's easy to feel lost. Build tools, package managers, loaders, bundlers, linters, compilers, transpilers, typecheckers - how do you make sense of it all? In this book, we will build a simple API and React application from scratch. We begin by setting up our development environment using Git, yarn, Babel, and ESLint. Then, we will use Express, Elasticsearch and JSON Web Tokens (JWTs) to build a stateless API service. For the front-end, we will use React, Redux, and Webpack. A central theme in the book is maintaining code quality. As such, we will enforce a Test-Driven Development (TDD) process using Selenium, Cucumber, Mocha, Sinon, and Istanbul. As we progress through the book, the focus will shift towards automation and infrastructure. You will learn to work with Continuous Integration (CI) servers like Jenkins, deploying services inside Docker containers, and run them on Kubernetes. By following this book, you would gain the skills needed to build robust, production-ready applications.
Table of Contents (26 chapters)
Title Page
Copyright and Credits
Dedication
Packt Upsell
Contributors
Preface
Free Chapter
1
The Importance of Good Code
Index

TDD


When we developed the Register page, we implemented the features before writing the test. We did this because we didn't know how E2E tests work with React. Now that we do, it's time to implement a proper TDD process.

To implement TDD, we should look at the design of the UI, identify key elements that our tests would need interact with, and assign each of them an unique id. These ids then form the contract between our tests and the implementation.

For instance, if we developed our Registration Page using TDD, we would first assign the inputs to the IDs #email, #password, and #register-button, and write our test code using these IDs to select the element. Then, when we implement the feature, we will make sure to use the same IDs as specified in the test.

By using an id field, we can change the implementation details but leave the tests untouched. Imagine if we used a different selector, say, form > input[name="email"]; then, if we add an inner wrapper within the <form> element, we...