Test Driven JavaScript Development- P4

Test Driven JavaScript Development- P4:This book is about programming JavaScript for the real world, using the techniquesand workflow suggested by Test-Driven Development. It is about gaining confidencein your code through test coverage, and gaining the ability to fearlessly refactor andorganically evolve your code base. It is about writing modular and testable code. Itis about writing JavaScript that works in a wide variety of environments and thatdoesn’t get in your user’s way.
Nội dung trích xuất từ tài liệu:
Test Driven JavaScript Development- P4 3.5 Summary 53 Although we visited the topics of test coverage reports and continuous integra- tion in this chapter, no setup or examples were given for such tools. On the book’s website1 you will find a guide to running the Coverage plugin for JsTestDriver as well as a guide on how to run JsTestDriver tests in the open source continuous integration server Hudson. In the next chapter we will have a look at some other ways to utilize unit tests before we move on to Part II, JavaScript for Programmers. 1. http://tddjs.comPlease purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com This page intentionally left blankPlease purchase PDF Split-Merge on www.verypdf.com to remove this watermar From the Library of WoweBook.Com Test to Learn 4 I n the previous three chapters we have seen how automated tests can help improve quality of code, guide design and drive development. In this chapter we will use automated tests to learn. As small executable code examples, unit tests make a perfect learning resource. Isolating a specific aspect of an interface in a unit test is a great way to learn more about how it behaves. Other types of automated tests can help our understanding of both the language and specific problems. Benchmarks are a valuable tool to measure relative performance, and can guide decisions about how to solve a specific problem. 4.1 Exploring JavaScript with Unit Tests Quickly executing JavaScript, as in executing a few lines of script to explore the behavior of some object, is fairly simple. Most modern browsers ship with a console that serves this purpose just fine. Additionally, there are several options for JavaScript command line interfaces when the browser environment is not of particular interest. Although this sort of one-off coding session can help our understanding of an inter- face, it suffers from the same problems that manual application testing does. There is no way to repeat a given experiment, there is no record of previously run experi- ments, and there is no simple way of repeating an experiment in multiple browsers. In Chapter 1, Automated Testing, we introduced unit tests as a means to solve the problems brought on by manual testing. Surely, unit tests can help us solve 55Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 56 Test to Learn the same problems when we want to simply explore an interface to learn. For this purpose we can write learning tests, i.e., unit tests written with the goal of learning, not with the goal of testing the exercised interface per se. As an example, let us take the built-in Array.prototype.splice method for a spin. This method accepts two or more arguments: an index to start with, a number of items to remove, and optional elements to insert into the array. We are curious as to whether or not this method alters the original array. We could look up the answer, or we could simply ask JavaScript to tell us, as the learning test in Listing 4.1 shows. To run the test, set up a JsTestDriver project as explained in Chapter 3, Tools of the Trade, with a test directory and save the test in a file in that directory. Add a configuration file that loads test/*.js. Listing 4.1 Expecting Array.prototype.splice to modify the array TestCase(ArrayTest, { test array splice should not modify array: function () { var arr = [1, 2, 3, 4, 5]; var result = arr.splice(2, 3); assertEquals([1, 2, 3, 4, 5], arr); } }); Because we don’t really know what the answer is, we roll with the assumption that the splice method is not destructive. Note how this contrasts with traditional unit testing—when testing production code we should always write assertions on firm expectation about the result. However, we are now learning by observing what the implementation can tell us, and so whatever answer we are assuming before run- ning the test is not of grave importance. Running the test proves us wrong anyway: “expected [1, 2, 3, 4, 5] but was [1, 2].” So we have learned something new. To record our findings, Listing 4.2 updates the test to state what we now know to be true. Listing 4.2 Array.prototype.splice modifies the receiving array TestCase(ArrayTest, { test array splice should modify array: function () { var arr = [1, 2, 3, 4, 5]; var result = arr.splice(2, 3); assertEquals([1, 2], arr); } });Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 4.1 E ...