Danh mục

Test Driven JavaScript Development- P3

Số trang: 20      Loại file: pdf      Dung lượng: 204.73 KB      Lượt xem: 17      Lượt tải: 0    
tailieu_vip

Hỗ trợ phí lưu trữ khi tải xuống: 19,000 VND Tải xuống file đầy đủ (20 trang) 0
Xem trước 2 trang đầu tiên của tài liệu này:

Thông tin tài liệu:

Test Driven JavaScript Development- P3: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- P3 1.3 Test Functions, Cases, and Suites 13 1.3.1 Setup and Teardown xUnit frameworks usually provide setUp and tearDown methods. These are called before and after each test method respectively, and allow for centralized setup of test data, also known as test fixtures. Let’s add the date object as a test fixture using the setUp method. Listing 1.12 shows the augmented testCase function that checks if the test case has setUp and tearDown, and if so, runs them at the appropriate times. Listing 1.12 Implementing setUp and tearDown in testCase function testCase(name, tests) { assert.count = 0; var successful = 0; var testCount = 0; var hasSetup = typeof tests.setUp == function; var hasTeardown = typeof tests.tearDown == function; for (var test in tests) { if (!/^test/.test(test)) { continue; } testCount++; try { if (hasSetup) { tests.setUp(); } tests[test](); output(test, #0c0); if (hasTeardown) { tests.tearDown(); } // If the tearDown method throws an error, it is // considered a test failure, so we dont count // success until all methods have run successfully successful++; } catch (e) { output(test + failed: + e.message, #c00); } }Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 14 Automated Testing var color = successful == testCount ? #0c0 : #c00; output( + testCount + tests, + (testCount - successful) + failures, color); } Using the new setUp method, we can add an object property to hold the test fixture, as shown in Listing 1.13 Listing 1.13 Using setUp in the strftime test case testCase(strftime test, { setUp: function () { this.date = new Date(2009, 9, 2, 22, 14, 45); }, test format specifier Y: function () { assert(%Y should return full year, this.date.strftime(%Y) == 2009); }, // ... }); 1.4 Integration Tests Consider a car manufacturer assembly line. Unit testing corresponds to verifying each individual part of the car: the steering wheel, wheels, electric windows, and so on. Integration testing corresponds to verifying that the resulting car works as a whole, or that smaller groups of units behave as expected, e.g., making sure the wheels turn when the steering wheel is rotated. Integration tests test the sum of its parts. Ideally those parts are unit tested and known to work correctly in isolation. Although high-level integration tests may require more capable tools, such as software to automate the browser, it is quite possible to write many kinds of integra- tion tests using a xUnit framework. In its simplest form, an integration test is a test that exercises two or more individual components. In fact, the simplest integration tests are so close to unit tests that they are often mistaken for unit tests. In Listing 1.6 we fixed the “y” format specifier by zero padding the re- sult of calling date.getYear(). This means that we passed a unit test for Date.prototype.strftime by correcting Date.formats.y. Had the lat- ter been a private/inner helper function, it would have been an implementationPlease purchase PDF Split-Merge on www.verypdf.com to remove this watermark. From the Library of WoweBook.Com 1.4 Integration Tests 15 detail of strftime, which would make that function the correct entry point to test the behavior. However, because Date.formats.y is a publicly available method, it should be considered a unit in its own right, which means that the afore- mentioned test probably should have exercised it directly. To make this distinction clearer, Listing 1.14 adds another format method, j, which calculates the day of the year for a given date. Listing 1.14 Calculating the day of the year Date.formats = { // ... j: function (date) { var jan1 = new Date(date.getFullYear(), 0, 1); var diff = date.getTime() - jan1.getTime(); // 86400000 == 60 * 60 * 24 * 1000 return Math.ceil(diff / 86400000); }, // ... }; The Date.formats.j method is slightly more complicated than the previous formatting methods. How should we test it? Writing a test that asserts on the result of new Date().strftime(%j) would hardly constitute a unit test for Date.formats.j. In fact, following the previous definition of integration tests, this sure looks like one: ...

Tài liệu được xem nhiều: