Read Online Test-Driven Development with React by Juntao Qiu Book, Low Cost Buy Test-Driven Development with React Book Instant Download, Juntao Qiu Author Book Download.
Overview: Apply test-driven principles to create scalable and maintainable React applications. This book covers a wide range of topics, including setting up a testing environment and utilizing popular testing frameworks like Cypress, Jest, and the React Testing Library. It also delves into valuable refactoring techniques, as well as enhancing code maintainability and readability. What sets this comprehensive guide apart is its end-to-end project simulation, showcasing how TDD can be employed to build a complete application called “Bookish.”
Test-Driven Development with React and TypeScript elevates its code examples by leveraging TypeScript, the predominant language in modern frontend development, offering you a deeper understanding of how TDD principles can be applied to React projects. Furthermore, all code examples have been carefully revised and updated for this edition, incorporating reader feedback and reflecting current industry standards.
After completing this book, you have the knowledge and skills necessary to develop high quality and scalable React applications.
What You Will Learn
Master essential refactoring techniques to enhance code quality
Employ modern practices for writing maintainable React code, including testing and product implementation
Gain practical experience applying test-driven development (TDD) principles to real-world projects
Craft high quality, scalable, and maintainable React applications using TDD principles and techniques
Who This Book Is For
Web application developers who wants to learn how to write high quality code using test-driven development.
Test-Driven Development with React by Juntao Qiu Book Read Online Chapter One
A Brief History of Test-Driven Development
Juntao Qiu1
(1)
Wantirna, 3152, VIC, Australia
My purpose in writing this chapter is not to copy and paste cliches from blogs or to make it seem like I was part of the historic events (such as the Agile Manifesto or Extreme Programming activities) that led to the creation of Test-Driven Development as a methodology – believe me, I’m not that old.
However, I do believe that providing context around the topics we’ll be discussing in this book can be helpful. In this chapter, we’ll explore the basic workflow of TDD and the various practical approaches used by different schools of thought. If you prefer to jump straight into the code, feel free to do so by navigating to the next chapter and getting your hands dirty.
What Is Test-Driven Development?
TDD is a software development methodology in which tests are written to drive the development of an application. It was developed/rediscovered by Kent Beck in the late 1990s as part of Extreme Programming1 and was well discussed in his famous book Test-Driven Development: By Example.
In his book, Kent Beck describes two essential rules:
•Write new code only if you first have a failing automated test
•Eliminate duplication
which leads to the steps of Red-Green-Refactor, which we will discuss soon. The ultimate goal for these two rules is to write (as Ron Jeffries describes) clean code that works.
The Red-Green-Refactor Cycle
Red-Green-Refactor is the core cycle of Test-Driven Development (TDD) methodology. The cycle involves the following steps:
1.
Red: Write a failing test that describes the desired behavior of a specific feature or functionality. The test should not pass yet as the functionality has not yet been implemented.
2.
Green: Write the minimum amount of production code necessary to make the failing test pass. The focus should be solely on passing the test, without worrying about code quality or design.
3.
Refactor: Improve the design of the production code without changing its behavior, ensuring that all tests continue to pass. This step includes optimizing the code, removing duplication, and enhancing its overall quality.
The cycle repeats with each new feature or functionality, with the goal of producing high-quality code that meets the specified requirements and is maintainable over time. The Red-Green-Refactor cycle (Figure 1-1) emphasizes writing automated tests before writing any production code, ensuring that the code is continually tested and improved as it evolves.
Figure 1-1 Test-Driven Development
At first glance, the principles may seem straightforward to follow. However, the challenge with many principles is that they may not work effectively for beginners. The principles are generally high level and challenging to implement, as they lack specificity and detailed guidance.
For example, just knowing the principles will not help you to answer questions like
•How can I write my very first test?
•What does enough code actually mean?
•When and how should I refactor?
•What refactoring techniques do I need to begin with?
This book aims to address these questions and equip you with the knowledge and skills necessary to apply these techniques with confidence in your daily workflow. By the end of the book, you should be well equipped to implement the discussed techniques effectively.
A Closer Look at Red-Green-Refactor
Examining the Red-Green-Refactor cycle more closely reveals something intriguing. To successfully integrate this method into our daily workflow, we must consider several additional elements.
Figure 1-2 Test-Driven Development. Source: Wikipedia (https://en.wikipedia.org/wiki/Test-driven_development)
Traditionally, TDD contains two major parts: quick implementation and then refactoring. In practice, the tests for quick implementation are not limited to the unit tests. They can be the acceptance tests as well – these are higher-level tests that focus more on business value and the end-user journey, without worrying too much about the technical details. Implementing the acceptance tests first could be an even better idea.
Starting with acceptance tests ensures that the right things are prioritized, and it provides confidence to developers when they want to clean up and refactor the code in the later stage. Acceptance tests are intended to be written from the end user’s perspective; a passing acceptance test ensures the code meets the business requirement. Additionally, it protects the developer from wasting time on false assumptions or invalid requirements.
When applying TDD, you need to keep in mind a simple principle from Extreme Programming: YAGNI, or You Aren’t Gonna Need It. YAGNI can be very useful for protecting developers from wasting their valuable time. Developers are very good at making assumptions around potential requirement changes, and based on those assumptions, they may come up with some unnecessary abstractions or optimizations that can make the code more generic or reusable. The problem is that those assumptions rarely turn out to be true. YAGNI emphasizes that you should not do it until you have to.
However, in the refactor phase, you can implement those abstractions and optimizations. Since you already have test coverage, it’s much safer to do the cleanup then. Small refactors such as Change Class Name, Extract Method, or Extract Class to a higher level – anything that helps to make the code more generic and SOLID2 are now safer and easier to undertake.
Types of TDD
Although TDD is a broad and diverse concept with many variations and different schools, such as UTDD, BDD, ATDD, and others, it traditionally implied Unit Test–Driven Development or UTDD. However, the TDD discussed in this book is an extended version of the conventional concept, known as Acceptance Test–Driven Development (ATDD), which places a strong emphasis on writing acceptance tests from the business perspective and using them to drive the development of production code.
Having various tests in different layers can ensure that we are always on the right track and have the correct functionality.
Implementing Acceptance Test–Driven Development
To put it succinctly, ATDD defines the behavior of software from the end user’s perspective by prioritizing the business value of the application rather than implementation details. Rather than validating that functions are called at specific times with correct parameters, ATDD ensures that when a user places an order, they receive their delivery on time.
We can merge the ATDD and UTDD into one diagram, as shown in Figure 1-3.
Figure 1-3 Acceptance Test–Driven Development
The diagram describes the following steps:
1.
Write an acceptance test and see it fail.
2.
Write a unit test and see it fail.
3.
Write code to make the unit test pass.
4.
Refactor the code.
5.
Repeat steps 2–4, until acceptance test passes.
When you look at this process closely, you find that during the development stage, the acceptance test could be failing for quite some time. The feedback loop turns out to be very long, and there is a risk that an always-failed test means no test (protection) at all.
Developers could be confused about whether there are defects in the implementation or whether there is any implementation at all.
To resolve this problem, you have to write acceptance tests in relatively small chunks, testing a tiny slice of the requirement at a time. Alternatively, you could use the “fake it until you make it” approach, as we are going to use across this book.
The steps almost remain the same; only an extra fake step is added:
1.
Write a failed acceptance test.
2.
Make it pass in the most straightforward way (a fake implementation).
3.
Refactor based on any code smells (like hard-coded data, magic number, etc.).
4.
Add another new test based on a new requirement (if we need a new acceptance test, go back to step 1; otherwise, the process is just like traditional TDD).
Note that in the second step, you can use hard coding or a snippet of static HTML to make the test pass. At first glance, that may look redundant, but you will see the power of fake in the next few chapters.
The benefit of this variation is that when a developer is refactoring, there is always a passing acceptance test protecting you from breaking existing business logic. The drawback of this approach is that when a developer doesn’t have enough experience, it can be difficult for them to come up with clean code designs – they could keep the fake in some way (e.g., a magic number, lack of abstractions, etc.).
Behavior-Driven Development
Another important variation of TDD is BDD, or Behavior-Driven Development. Behavior-Driven Development is an agile practice that encourages collaboration among different roles, developers, quality engineers, business analysts, or even other interested parties in a software project.
Although BDD is to some extent a general idea about how software development should be managed by both business interests and technical insight, the practice of BDD involves some specialized tools. For example, a Domain-Specific Language (DSL) is used to write tests in natural language that can be easily understood by nontechnical people and can be interpreted by code and executed behind the scenes.
The following code snippet of a BDD test case shows how a requirement can be described:
Given there are 10 books in the library
When a user visits the homepage
Then they would see 10 books on the page
And each book would contain at least name, author, price and rating
We’ll discuss this in detail in Chapter 10.
Prerequisites of TDD
To be candid, TDD can be a challenging methodology to apply. Several prerequisites must be met before implementing it effectively. A crucial prerequisite for TDD is a developer’s ability to detect code smells and refactor them toward better design. Suppose, for example, you encounter smelly code, such as a lack of abstractions or magic numbers, and are unsure how to improve it. In that case, TDD alone may not be sufficient. While the TDD workflow must be followed, there is a risk of creating unmaintainable tests in addition to producing low-quality code.
Be Aware of Code Smell and Refactoring
In his book Refactoring: Improving the Design of Existing Code, Martin Fowler listed 68 refactorings. I would recommend this book as almost a mandatory prerequisite for anyone who values clean code and high-quality code. But don’t worry too much, some of the refactorings he mentioned you may have already used in your daily work.
As mentioned earlier, a typical TDD workflow has three steps:
•A test case description requirement (specification)
•Some code to make the test pass
•Refactor the implementation and tests
It is a common misconception that test code is secondary or does not hold the same level of importance as production code. However, I would contend that test code is equally as crucial as production code. Maintainable tests are crucial to people who have to make changes later on or add new ones. Every time you refactor, make sure the changes made in the production code are reflected in the test code.
Test First or Test Last
The hardest part of applying TDD in your daily workflow is that you have to write tests before you start writing any production code. For most developers, that’s not just different and counterintuitive but also breaks their own way of working significantly.
Nevertheless, the key to applying TDD is that you should build the fast feedback mechanism first. Once you have it, it doesn’t matter much if you write the test first or last. By fast feedback, I mean that a method or an if-else branch can be tested in a very lightweight and effortless manner. If you add tests after all the functionality has been completed, you are not doing TDD by any means. Because you are missing the essential fast feedback loop – seen as the most important thing in development – you may also be missing the benefits promised by TDD.
By implementing a fast feedback loop, TDD ensures you are always on the right track – safely. It also gives you sufficient confidence to do the further code cleanup. And proper code cleanup can lead to a better code design. Of course, the cleanup does not come automatically, it requires extra time and effort. However, TDD is a great mechanism to protect you from breaking the application when you are making changes.
Other Techniques That Can Help Implement TDD
For the beginner, it can be challenging when applying TDD as it sometimes feels counterintuitive to test first. In practice, there are common reasons for resistance to TDD:
•For simple tasks, they don’t need TDD.
•For complicated tasks, setting up the TDD mechanism itself can be too difficult.
There are a lot of tutorials and articles out there to describe techniques you should use to do TDD, and some may even involve describing how to split tasks before implementing TDD. However, things discussed in those tutorials are often oversimplified and can be hard to apply to a real-world project directly.
For example, in a web application, both the interaction and a considerable portion of business logic now exist in the frontend: the UI. The traditional techniques of how to write a unit test to drive backend logic are already outdated.
Tasking
Another critical skill required by TDD is splitting a large requirement into smaller chunks through tasking. I would suggest every developer should learn how to split requirements before they even start to write their first test.
We’ll discuss the tasking process in detail in the next chapter.
Maintaining a Simple Checklist
Usually, we can stop at the second round of splitting, since the Red-Green-Refactor is far too detailed in terms of tasking. And too granular tasks means more management effort (tracking those tasks needs more energy). To make the tasks visible, we can put it down on a post-it note and mark a simple tick once it’s done (Figure 1-4).
By using this simple tool, you can then focus on what you’re going to do and make the progress more accurate when you want to update it to other team members (e.g., in the daily stand-up meeting). By saying a task is 50% done, half of the items on the list are ticked off on the list you made earlier.
Figure 1-4 Tasking with sticky notes
Summary
Refactoring depends on the sense and experience of identifying code smells. Once you find a code smell, you can then apply the corresponding refactoring technique. And then we may achieve maintainable, human-readable, extendable, and clean code along the way.
In the next chapter, we will introduce a concrete example to demonstrate how to apply TDD step by step. Along with that example, we will also cover the fundamental skills needed for implementing TDD, including how to use the jest testing framework and how to do tasking with real-world examples.
Read Online Only First Chapter Of Test-Driven Development with React by Juntao Qiu Book. If You Like First Chapter So Buy Online Complete Book
This Book Epub File Download Only Pay 5.60 Usd
✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋✋
Note :- If After Pay Any Download Problem Or Error So Contact Us In Email.
This Download File Is Epub Format. This File Open In Epub Viewer Software. So Epub Viewer Software Download Go This Website For.
1 – Website https://calibre-ebook.com
2 – Website www.epubfilereader.com
