Kent Beck - Test Driven Development: By Example
Here you can read online Kent Beck - Test Driven Development: By Example full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. year: 2002, publisher: Addison-Wesley Professional, genre: Humor. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:
Romance novel
Science fiction
Adventure
Detective
Science
History
Home and family
Prose
Art
Politics
Computer
Non-fiction
Religion
Business
Children
Humor
Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.
Test Driven Development: By Example: summary, description and annotation
We offer to read an annotation, description, summary or preface (depends on what the author of the book "Test Driven Development: By Example" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.
Kent Beck: author's other books
Who wrote Test Driven Development: By Example? Find out the surname, the name of the author of the book and a list of all author's works by series.
![Percival - Test-driven web development with Python: [obey the testing goat: using Django, Selenium, and JavaScript]](/uploads/posts/book/248536/thumbs/percival-test-driven-web-development-with-python.jpg)
Test Driven Development: By Example — read online for free the complete book (whole text) full work
Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Test Driven Development: By Example" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.
Font size:
Interval:
Bookmark:
Appendix I. Influence Diagrams This book contains many examples of influence diagrams. The idea of influence diagrams is taken from Gerald Weinberg's excellent Quality Software Management series, particularly Book 1: Systems Thinking . The purpose of an influence diagram is to see how the elements of a system affect one another. [1] Weinberg, Gerald. 1992. Systems Thinking . Quality Software Management . New York: Dorset House. ISBN: 0932633226. Influence diagrams have three elements:
A lot of words for a simple concept. provide a few examples. The more I eat, the more I weigh. The less I eat, the less I weigh. Personal weight is a far more complicated system than this, of course. Influence diagrams are models to help you understand some aspect of the system, not understand and control it perfectly. Figure A.1. Two seemingly unrelated activities
Figure A.2. Positively connected activities
Figure A.3. Negatively connected activities
|
Feedback Influence doesn't work in one direction only. Often the effects of an activity come back around to change the activity itself, either positively or negatively, as shown in . Figure A.4. Feedback
If my weight rises, then my self-esteem drops, which makes we want to eat more, which makes my weight rise, and so on. Anytime you have a cycle in an influence diagram, you have feedback. There are two kinds of feedbackpositive and negative. Positive feedback causes systems to encourage more and more of an activity. You can find positive feedback loops by counting the number of negative connections in a cycle. If there are an even number of negative connections, then you have a positive feedback loop. The feedback loop in is a positive feedback loop. It will cause you to keep gaining weight until the influence of some other activity kicks in. Negative feedback damps or reduces an activity. Cycles with an odd number of negative connections are negative feedback loops. The keys to system design are
System Control When choosing a system of software development practices, you'd like the practices to support one another so that you tend to do about the right amount of any activity, even under stress. is an example of a system of practices that leads to insufficient testing. Figure A.5. Not enough time to test reduces the available time
Under the pressure of time, you reduce the amount of testing, which increases the number of errors, which increases the time pressure. Eventually some outside activity (like "Cash Flow Panic") steps in to ship the software regardless. When you have a system that isn't behaving, you do have options.
|
Appendix II. Fibonacci In answer to a question from one of the reviewers of this book, I posted a test-driven Fibonacci. Several reviewers commented that this example turned on their light about how TDD works. However, it is not long enough, nor does it demonstrate enough of TDD techniques, to replace the existing examples. If your lights are still dark after reading the main examples, take a look here and see. The first test shows that fib(0) = 0. The implementation returns a constant. public void testFibonacci() { assertEquals(0, fib(0)); } int fib( int n) { return 0; }(I am just using the TestCase class as a home for the code, because it is only a single function.) The second test shows that fib(1) = 1. public void testFibonacci() { assertEquals(0, fib(0)); assertEquals(1, fib(1)); }I just put the second assert in the same method, because there didn't seem to be any substantial communication value to writing testFibonacciOfOneIsOne. There are several ways I could go to make this run. I'll choose to treat 0 as a special case: int fib( int n) { if (n == 0) return 0; return 1; }The duplication in the test case is starting to bug me, and it will only get worse as we add new cases. We can factor out the common structure of the assertions by driving the test from a table of input and expected values. public void testFibonacci() { int cases[][]= {{0,0},{1,1}}; for (int i= 0; i < cases.length; i++) assertEquals(cases[i][1], fib(cases[i][0])); }Now adding the next case requires six keystrokes and no additional lines: public void testFibonacci() { int cases[][]= {{0,0},{1,1},{2,1}}; for ( int i= 0; i < cases.length; i++) assertEquals(cases[i][1], fib(cases[i][0])); }Disconcertingly, the test works. It just so happens that our constant 1 is right for this case as well. On to the next test: public void testFibonacci() { int cases[][]= {{0,0},{1,1},{2,1},{3,2}}; for ( int i= 0; i < cases.length; i++) assertEquals(cases[i][1], fib(cases[i][0])); }Hooray, it fails. Applying the same strategy as before (treating smaller inputs as special cases), we write: int fib( int n) { if (n == 0) return 0; if (n <= 2) return 1; return 2; }Now we are ready to generalize. We wrote 2, but we don't really mean 2, we mean 1 + 1. int fib( int n) { if (n == 0) return 0; if (n <= 2) return 1; return 1 + 1; }That first 1 is an example of fib(n-1): int fib( int n) { if (n == 0) return 0; if (n <= 2) return 1; return fib(n-1) + 1; }The second 1 is an example of fib(n-2): int fib( int n) { if (n == 0) return 0; if (n <= 2) return 1; return fib(n-1) + fib(n-2); } |
Font size:
Interval:
Bookmark:
Similar books «Test Driven Development: By Example»
Look at similar books to Test Driven Development: By Example. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.
Discussion, reviews of the book Test Driven Development: By Example and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.