Testing
At some point during every project, there will inevitably be two questions that need answering for each change you make: does it work, and has it broken anything? Testing can be used to answer these two questions, although there are subtle differences bet
- PDF / 211,217 Bytes
- 17 Pages / 504 x 720 pts Page_size
- 110 Downloads / 252 Views
Testing At some point during every project, there will inevitably be two questions that need answering for each change you make: does it work, and has it broken anything? Testing can be used to answer these two questions, although there are subtle differences between the types of testing used to resolve them.
Test-Driven Development Test-driven development (TDD) is a well-established technique for developing software, although it is often misunderstood. The purpose of TDD is not to generate high test coverage, but to use tests to help drive the design of your code; TDD is really about development, not just tests. TDD is based on a cycle of “red-green-refactor.” At first, you write a test for the new functionality you want to add, which should fail (go red), and then you write the simplest bit of functionality to make the test pass (go green). Once you have done this, you can refactor your application and test code to tidy it up and remove duplication. In test-driven development, it is common to write tests that only address a single module at a time. These types of tests are known as unit tests, as opposed to integration tests, which are discussed further later in the chapter, and which test multiple modules at once. Some people, especially those who practice behavior-driven development, will often start by writing a test that’s wider than one particular module, and then write the necessary tests with a smaller scope that satisfies the requirements of the bigger test— this is the outside-in approach. Others prefer to start at the smallest unit and then write integration tests to wire the modules together once they have been built, referred to as the inside-out approach. It is often a matter of personal style as to which approach you go for, although proponents of the outside-in approach say it helps them decide which components need to be written, and proponents of the inside-out approach like the flexibility of not having to design the interfaces of the individual modules in advance. © Chris Northwood 2018 C. Northwood, The Full Stack Developer, https://doi.org/10.1007/978-1-4842-4152-3_7
141
Chapter 7
Testing
If you have issues writing tests that only target one module, that might suggest that there are several highly coupled modules that might actually be better joined as one, or, if there are multiple distinct types of tests for that one module, that your one module should in fact be split into multiple smaller ones. “Arrange-act-assert” (sometimes called “given-when-then,” especially when used with behavior-driven development, discussed later in this chapter) is a common pattern for arranging your test code. Take the example below: it('should increase the size of the shopping cart when adding a new item to it', () => { const cart = new ShoppingCart(); const product = fetchTestProduct(); cart.add(product); expect(cart.size()).toEqual(1); }); Here, the arrange-act-assert process is shown using white space, which is a common p
Data Loading...
