What do you think?
Rate this book
A Kent Beck Signature Book
TDD Desenvolvimento Guiado por Testes
Este livro ilustra com exemplos práticos e reais como codificar e executar testes automatizados. O TDD (prática que surgiu na XP) é apresentado de modo simples e são abordadas algumas respostas a problemas e dúvidas comuns. O texto tem uma linguagem informal, criando a impressão de que o autor e o leitor estão juntos numa atividade real de desenvolvimento de software, trocando ideias, levantando dúvidas e realizando tarefas passo a passo.
Kindle Edition
First published January 1, 2002
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 208 reviews
May 30, 2012
This is one of those books that I would have rated more highly a few years ago. TDD is not a particularly complicated concept and, these days, it's not particularly new either. Thus, the explanations I've come across online[1] and the one book I've read on the topic[2] have been quite sufficient exposure, making reading another book on the topic superfluous.
That said, Beck's book was, in my opinion, better than Test-Driven Development: A Practical Guide by David Astels. Astels' book is not bad, but it's over 500 pages long, and TDD just isn't really that complicated. Beck's book, at ~200 pages of fairly spacious typesetting, is much more proportional to the complexity of the topic (websites are even shorter, but I prefer to read books, especially when they are available from the library at work).
In short, if you are interested in learning about TDD -- and I think it's an approach all programmer should learn about and apply judiciously but not religiously -- I recommend reading about it on the internet and then, if you're a book person or want to see a more extended example, read Beck's book.
[1] http://en.wikipedia.org/wiki/Test-dri... and http://www.agiledata.org/essays/tdd.html
[2] test-driven development: A Practical Guide by David Astels
That said, Beck's book was, in my opinion, better than Test-Driven Development: A Practical Guide by David Astels. Astels' book is not bad, but it's over 500 pages long, and TDD just isn't really that complicated. Beck's book, at ~200 pages of fairly spacious typesetting, is much more proportional to the complexity of the topic (websites are even shorter, but I prefer to read books, especially when they are available from the library at work).
In short, if you are interested in learning about TDD -- and I think it's an approach all programmer should learn about and apply judiciously but not religiously -- I recommend reading about it on the internet and then, if you're a book person or want to see a more extended example, read Beck's book.
[1] http://en.wikipedia.org/wiki/Test-dri... and http://www.agiledata.org/essays/tdd.html
[2] test-driven development: A Practical Guide by David Astels
April 30, 2010
This book has a simple purpose: show in clear and understandable language how to approach TDD. Nothing more or less, and he succeeds very well.
Other reviewers have commented that they were annoyed about how this book didn't cover mocks and stubs and a lot of the other artefacts of testing - that wasn't Beck's purpose, he wanted to show how it's done and then catalogue the patterns needed in order to make it work. While he covered mock and null objects he didn't go into the details because these are very much part of the testing framework you are using and the limitations of the language you are working with. They will be covered (to death) in the documentation associated with it - the ideas, the principles, they work everywhere.
I will use this book the next time I teach TDD, and I will use the patterns section the next time I get stuck. I also liked the section where he uses the ideas in TDD to develop an xUnit framework using Python - using the ideas to develop the framework is a very useful approach. He also says that this is how he learns new languages - implement the xUnit framework in them. Which also then gives you what you need if you're going to get "serious" and write something longer.
The other thing that struck me was that, like Bob Martin in Agile Software Development Principles Patterns and Practices, he talks about finding design patterns as you work. Martin talks about "backing into" a pattern, this book has an afterword my Martin Fowler that says similar things, the pattern comes out of the refactoring and you implement it in a way that makes sense for the problem in front of you. Avoid the endless, sterile project meetings about which variant of what pattern - write some tests, understand the problem and then "back into" an appropriate pattern, if you need to. But get it done and move on.
Other reviewers have commented that they were annoyed about how this book didn't cover mocks and stubs and a lot of the other artefacts of testing - that wasn't Beck's purpose, he wanted to show how it's done and then catalogue the patterns needed in order to make it work. While he covered mock and null objects he didn't go into the details because these are very much part of the testing framework you are using and the limitations of the language you are working with. They will be covered (to death) in the documentation associated with it - the ideas, the principles, they work everywhere.
I will use this book the next time I teach TDD, and I will use the patterns section the next time I get stuck. I also liked the section where he uses the ideas in TDD to develop an xUnit framework using Python - using the ideas to develop the framework is a very useful approach. He also says that this is how he learns new languages - implement the xUnit framework in them. Which also then gives you what you need if you're going to get "serious" and write something longer.
The other thing that struck me was that, like Bob Martin in Agile Software Development Principles Patterns and Practices, he talks about finding design patterns as you work. Martin talks about "backing into" a pattern, this book has an afterword my Martin Fowler that says similar things, the pattern comes out of the refactoring and you implement it in a way that makes sense for the problem in front of you. Avoid the endless, sterile project meetings about which variant of what pattern - write some tests, understand the problem and then "back into" an appropriate pattern, if you need to. But get it done and move on.
October 3, 2018
I should have read this book earlier. When the whole TDD thing exploded, the web was, for a while, plastered with blog posts and tutorials on the whys and hows of TDD and unit tests. Everyone agreed that automated testing was a great thing; the opinions differed only on when to write the tests, and what the units under test should be. I thought I had understood and soaked in the main tenets of TDD, and did not need to read this relatively small book.
So, what is TDD? It's a development method where you have to follow a very simple algorithm, but to the letter. Start with some code, and a set of tests that are green, meaning they compile and the assertions are all correct. No code and no tests count as green. Write a test that fails - this is red. The failure can be a failing assertion or a compiler error. The test that fails is free to contain the perfect interface that is not implemented; in this sense, TDD can also be called interface-first programming, but I'm probably not the first one to make that point. In the next step, make the failure go away by changing code. Once you have a working test, refactor to make duplication go away. This is the famous red-green-refactor loop. There are many nuances to this loop, of course. For example, how to reduce duplication is left to the developer, but it's obvious that you shouldn't just be copying all input/output pairs in the test and functional code. In case you were asking yourself why the TDD way of working is so strictly codified, Kent Beck answers that question on p. 202: "by reducing repeatable behavior to rules, applying the rules becomes rote and mechanical...When along comes an exception, or a problem that just doesn't fit any of the rules, you have more time and energy to generate and apply creativity".
Not every kind of test is suitable for TDD. The tests have to be explicitly unit tests. They have to be fast, so that you can run them as often as you want, preferably after each save to make sure you haven't broken anything. They have to be independent from each other,so that one failing doesn't jeopardize the others; essentially, you should be able to run them in a random order. They should be orthogonal, i.e. test different aspects of whatever is being tested,so that when an aspect of the code under test changes, you don't have to adapt multiple tests. Unit tests should also not rely on environment conditions that could change (network, files), or services (database). In sum, a test suite (the sum of the unit tests for a module) should give you quick, precise feedback, reliably.
Why do this? Why not just sit down and bang code out? One could just as well apply the Feynman method in physics to programming, which consists of the following steps: Write down the problem, think, write down the solution. Proving that working in the TDD way is worth it is the whole point of this book. The main reason a developer should be doing TDD is that it's good for him; that is, it's about the psychology of development. Unit tests give you the support to work without stress, and try out new ideas all the time. You can write the smallest test possible, solve it in the most simple way imaginable (i.e. return a constant), and then move on the refactoring with the knowledge that the test is there. Since the unit tests are fast, you can just try something out, and quickly see what is failing. One 'aha'moment happened for me when Kent Beck went on a few pages with some extremely simple logic (multiplying currency values), improving first the test then the code. At the end of what I thought was an inane display, he pointed out that "TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps" (p. 9). You can ridicule TDD all you want for allowing too small steps, but this shows that TDD allows you to take steps of arbitrary size, which helps immensely when you are in a difficult place. Or as stated on p. 42,"TDD is a steering process. There is no right step size, now and forever".
Another really important effect of unit tests which I have also observed in my daily work, and can be used as a lever for productivity, is concentrating on what's next. Even if you don't follow TDD, having exactly one failing test, and trying to get it to work, while noting down all distractions to deal with later, is a great boon for productivity. When there is no such lens to focus the attention, developers are prone to code for hours without finishing anything particular, working on first this one feature, and then on some other. Keeping to the one failing test helps avoid such meandering.
And then there is the topic of design. One of the most disputed arguments of TDD has been that it takes care of design, at least to a certain extent. Design is handled in this book in the context of refactoring and design patterns. Kent Beck argues that the original design patterns book has a bias towards design as a phase, and not as a part of refactoring, which I would tend to agree. In TDD, on the other hand, design happens mostly in the refactoring that aims to remove duplication. By keeping the tests green while improving design,the developer can "Code for tomorrow, design for today" (p. 195). This is one place where I think Kent Beck is kind of cheating. Here is where he is right: As stated on p. 203, TDD shortens the feedback on design decisions. When you decide to change the interface of a unit,and see how many tests would fail in which way, the decision is much easier to make then if the tests were missing. However, I think Beck is overlooking the fact that in order to get design right with TDD,you need to be able to recognize good design when you see it, and this is not a small thing. TDD makes it easier to navigate the space of possible designs and interfaces. This fact is attested by another interesting observation made by the author, that "Doing a refactoring based on a couple of early uses, then having to undo it soon after is fairly common" (p. 102). Recognizing design that has to be undone,however, is a part of software wisdom, and requires long years of experience, and cannot be really simply achieved only with TDD.
One aspect where TDD helps immensely with design, however, is in terms of cohesion and coupling. Cohesion refers to how focused a class is on the task it should perform, whereas coupling is a measure of how dependent various classes are on each other. When the above points on good unit tests are observed (independence, orthogonality), they point naturally to a breakdown of the domain in terms of classes with high cohesion and low coupling. Or in Kent Beck's words, "I never knew exactly how to achieve high cohesion and loose coupling regularly until I started writing isolated tests" (p. 125).
There are a couple of things that disturbed me about the book,though. I was surprised at the weird snark in some places. On page 68,for example, Beck writes "the methods have to be public because methods in interfaces have to be public (for some excellent reason,I'm sure)". It's pretty obvious why, actually. An interface is by definition a record of what is open to the rest of the system. Why would one want to check for private methods in an interface declaration? That's a matter of implementation, and internal business of the class. Also, the writing is sometimes affectedly indirect and humorous. There are two paragpraphs on p. 124 telling an anecdote, and for the life of me, I can't understand either what happens or what it's supposed to mean. Due to this affected tone in some places, I could not discern whether some advice (e.g. on p. 138) was meant as humor or not. In this particular case ("If you don't know what to type, then take a shower, and stay in the shower until you know what to type") if it wasn't humour, it was rather shallow advice, too.
No matter what you make of TDD, this book sets the record straight on what it actually means, and why you should practice it. If you care about quality software or testing, you should definitely read it.
So, what is TDD? It's a development method where you have to follow a very simple algorithm, but to the letter. Start with some code, and a set of tests that are green, meaning they compile and the assertions are all correct. No code and no tests count as green. Write a test that fails - this is red. The failure can be a failing assertion or a compiler error. The test that fails is free to contain the perfect interface that is not implemented; in this sense, TDD can also be called interface-first programming, but I'm probably not the first one to make that point. In the next step, make the failure go away by changing code. Once you have a working test, refactor to make duplication go away. This is the famous red-green-refactor loop. There are many nuances to this loop, of course. For example, how to reduce duplication is left to the developer, but it's obvious that you shouldn't just be copying all input/output pairs in the test and functional code. In case you were asking yourself why the TDD way of working is so strictly codified, Kent Beck answers that question on p. 202: "by reducing repeatable behavior to rules, applying the rules becomes rote and mechanical...When along comes an exception, or a problem that just doesn't fit any of the rules, you have more time and energy to generate and apply creativity".
Not every kind of test is suitable for TDD. The tests have to be explicitly unit tests. They have to be fast, so that you can run them as often as you want, preferably after each save to make sure you haven't broken anything. They have to be independent from each other,so that one failing doesn't jeopardize the others; essentially, you should be able to run them in a random order. They should be orthogonal, i.e. test different aspects of whatever is being tested,so that when an aspect of the code under test changes, you don't have to adapt multiple tests. Unit tests should also not rely on environment conditions that could change (network, files), or services (database). In sum, a test suite (the sum of the unit tests for a module) should give you quick, precise feedback, reliably.
Why do this? Why not just sit down and bang code out? One could just as well apply the Feynman method in physics to programming, which consists of the following steps: Write down the problem, think, write down the solution. Proving that working in the TDD way is worth it is the whole point of this book. The main reason a developer should be doing TDD is that it's good for him; that is, it's about the psychology of development. Unit tests give you the support to work without stress, and try out new ideas all the time. You can write the smallest test possible, solve it in the most simple way imaginable (i.e. return a constant), and then move on the refactoring with the knowledge that the test is there. Since the unit tests are fast, you can just try something out, and quickly see what is failing. One 'aha'moment happened for me when Kent Beck went on a few pages with some extremely simple logic (multiplying currency values), improving first the test then the code. At the end of what I thought was an inane display, he pointed out that "TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps" (p. 9). You can ridicule TDD all you want for allowing too small steps, but this shows that TDD allows you to take steps of arbitrary size, which helps immensely when you are in a difficult place. Or as stated on p. 42,"TDD is a steering process. There is no right step size, now and forever".
Another really important effect of unit tests which I have also observed in my daily work, and can be used as a lever for productivity, is concentrating on what's next. Even if you don't follow TDD, having exactly one failing test, and trying to get it to work, while noting down all distractions to deal with later, is a great boon for productivity. When there is no such lens to focus the attention, developers are prone to code for hours without finishing anything particular, working on first this one feature, and then on some other. Keeping to the one failing test helps avoid such meandering.
And then there is the topic of design. One of the most disputed arguments of TDD has been that it takes care of design, at least to a certain extent. Design is handled in this book in the context of refactoring and design patterns. Kent Beck argues that the original design patterns book has a bias towards design as a phase, and not as a part of refactoring, which I would tend to agree. In TDD, on the other hand, design happens mostly in the refactoring that aims to remove duplication. By keeping the tests green while improving design,the developer can "Code for tomorrow, design for today" (p. 195). This is one place where I think Kent Beck is kind of cheating. Here is where he is right: As stated on p. 203, TDD shortens the feedback on design decisions. When you decide to change the interface of a unit,and see how many tests would fail in which way, the decision is much easier to make then if the tests were missing. However, I think Beck is overlooking the fact that in order to get design right with TDD,you need to be able to recognize good design when you see it, and this is not a small thing. TDD makes it easier to navigate the space of possible designs and interfaces. This fact is attested by another interesting observation made by the author, that "Doing a refactoring based on a couple of early uses, then having to undo it soon after is fairly common" (p. 102). Recognizing design that has to be undone,however, is a part of software wisdom, and requires long years of experience, and cannot be really simply achieved only with TDD.
One aspect where TDD helps immensely with design, however, is in terms of cohesion and coupling. Cohesion refers to how focused a class is on the task it should perform, whereas coupling is a measure of how dependent various classes are on each other. When the above points on good unit tests are observed (independence, orthogonality), they point naturally to a breakdown of the domain in terms of classes with high cohesion and low coupling. Or in Kent Beck's words, "I never knew exactly how to achieve high cohesion and loose coupling regularly until I started writing isolated tests" (p. 125).
There are a couple of things that disturbed me about the book,though. I was surprised at the weird snark in some places. On page 68,for example, Beck writes "the methods have to be public because methods in interfaces have to be public (for some excellent reason,I'm sure)". It's pretty obvious why, actually. An interface is by definition a record of what is open to the rest of the system. Why would one want to check for private methods in an interface declaration? That's a matter of implementation, and internal business of the class. Also, the writing is sometimes affectedly indirect and humorous. There are two paragpraphs on p. 124 telling an anecdote, and for the life of me, I can't understand either what happens or what it's supposed to mean. Due to this affected tone in some places, I could not discern whether some advice (e.g. on p. 138) was meant as humor or not. In this particular case ("If you don't know what to type, then take a shower, and stay in the shower until you know what to type") if it wasn't humour, it was rather shallow advice, too.
No matter what you make of TDD, this book sets the record straight on what it actually means, and why you should practice it. If you care about quality software or testing, you should definitely read it.
October 18, 2020
3/5 is stiłl more than a half. The book has a good content but I feel disappointed, why?
3/5 If you already are into TDD and you have some refactoring skills you won't learn much. You can organize your knowledge and habits and that's it.
5/5 if you are no sayer to tests or you begin with software development. If you do "test last development" or you don't test at all this is highly recommended book.
I didn't like the humour - it felt really artificial. What is more the other book I read by Beck - XP was far more better written and organised.
The price you pay for the book is not fair. The topic is broad. You may try to find answers for your questions which you have been asking for many months if not years and you won't find them. For me the free uncle bob blog posts about tdd influenced me more then whole book.
The money chapter is both good an bad - good because it learns you small steps and one problem at time attitude (but so does xunit chapter). Bad because it don't address the use case from introduction. What about existing code? What about existing tests? What about persistence? Apis? It felt like a lie - First Beck says we have to change something crucial in existing app but then Beck behaves like doing medium-sized change in greenfield project.
Note that every opinion is biased so is mine and I tried to address that in the review. After 10 years in IT I gave 3/5 but I am sure that I would give it 5/5 with a half of the expierence.
3/5 If you already are into TDD and you have some refactoring skills you won't learn much. You can organize your knowledge and habits and that's it.
5/5 if you are no sayer to tests or you begin with software development. If you do "test last development" or you don't test at all this is highly recommended book.
I didn't like the humour - it felt really artificial. What is more the other book I read by Beck - XP was far more better written and organised.
The price you pay for the book is not fair. The topic is broad. You may try to find answers for your questions which you have been asking for many months if not years and you won't find them. For me the free uncle bob blog posts about tdd influenced me more then whole book.
The money chapter is both good an bad - good because it learns you small steps and one problem at time attitude (but so does xunit chapter). Bad because it don't address the use case from introduction. What about existing code? What about existing tests? What about persistence? Apis? It felt like a lie - First Beck says we have to change something crucial in existing app but then Beck behaves like doing medium-sized change in greenfield project.
Note that every opinion is biased so is mine and I tried to address that in the review. After 10 years in IT I gave 3/5 but I am sure that I would give it 5/5 with a half of the expierence.
March 10, 2009
This is a different kind of programming book. It's a relatively fun book to read.
It's a good companion's to Fowler's Refactoring. For some reason, I'll always remember Beck from his 'coding smells' concept - it comes from his grandma saying "if it smells [bad:], change it" or something like that.
It too is non-intuitive at first and goes against a lot of learnings. But, all great concepts start out that way. It essentially tells you to write your tests first and (only then), write the smallest amount of code strictly necessary to make your tests pass - and nothing more. Then, refactor.
Repeat and write some more tests that bring you closer to conformance with requirements. Write just the code that will make your tests pass. Refactor.
Repeat until your tests conform with requirements. Conformance with requirements is a general objective around quality management such as Crosby's zero defects and 'quality is free'.
It's a good companion's to Fowler's Refactoring. For some reason, I'll always remember Beck from his 'coding smells' concept - it comes from his grandma saying "if it smells [bad:], change it" or something like that.
It too is non-intuitive at first and goes against a lot of learnings. But, all great concepts start out that way. It essentially tells you to write your tests first and (only then), write the smallest amount of code strictly necessary to make your tests pass - and nothing more. Then, refactor.
Repeat and write some more tests that bring you closer to conformance with requirements. Write just the code that will make your tests pass. Refactor.
Repeat until your tests conform with requirements. Conformance with requirements is a general objective around quality management such as Crosby's zero defects and 'quality is free'.
October 18, 2015
This is a future classic and exactly what you need to refine your test-first development skills. Even if you thought you were doing TDD before reading this book you may have been missing some extremely simple and yet powerful tricks Beck has up his sleeve and is happy to share. Try solving some simple problems TDD as you read it and you will know what to pay attention to as you read on.
On a side note the author shares his cheeky personality as he writes which makes reading even more fun.
On a side note the author shares his cheeky personality as he writes which makes reading even more fun.
October 8, 2021
Before reading this book, I was thinking about TDD as a testing technique. Besides that, I read some random quotes from Kent Beck and some presentations, and kinda fell in love with this man's mindset.
This book, amazingly, made me correct my thoughts about TDD, Agile, and Development! Kent Beck, with his realistic discussions and jokes in the book, taught me how to think better about these concepts.
By reading this book I got that "TDD is a technique for all the activities of the development", and how it makes you have confidence while developing.
Also, I really enjoyed this phrase from Kent Beck: "Partly this is because this is how I learn- I find an expert to act like, then gradually figure out what is really going on. I'm certainly not looking for the rules to be followed mechanically, although that is how the mechanically minded have interpreted them."
In Persian:
قبل از این که این کتاب رو بخونم، به تیدیدی به عنوان یک تکنیک تست کردن نگاه میکردم. از طرفی یک سری جملات و ارائههایی رو از کنت بک و سایر افراد در این خصوص دیده بودم و به شدت عاشق تفکراتش شدم.
این کتاب، به شکل خارق العادهای باعث شد تا من ذهنیتم رو در خصوص تیدیدی، اجایل و همینطور توسعه بهتر کنم. کنت بک با صحبتهای خوب و واقعگرایانهش و جوکهایی که تو متن کتاب داشت، بهم یاد داد تا چطور در خصوص این کانسپتها بهتر فکر کنم.
با خوندن این کتاب من فهمیدم که « تیدیدی یک تکنیک برای تمام فعالیتهای توسعهی نرمافزار هست » و چطور میشه با استفاده ازش اطمینان بیشتری هنگام توسعه داشت.
در کنار این توضیحات، من به شدت از این عبارت کنت بک تو کتاب لذت بردم: « این نسبتا به خاطر مدلی هست که من یاد میگیرم- من یک آدم حرفهای رو پیدا میکنم تا بتونم شبیهش رفتار کنم، بعد به مرور دستم میاد که دقیقا چه اتفاقی داره میافته. من دنبال پیدا کردن یه سری قاعده برای پیروی مکانیکال ازش نیستم، در حالی که این همون مدلی هست که آدمهای با ذهنهای مکانیکی ازش برداشت میکنن »
This book, amazingly, made me correct my thoughts about TDD, Agile, and Development! Kent Beck, with his realistic discussions and jokes in the book, taught me how to think better about these concepts.
By reading this book I got that "TDD is a technique for all the activities of the development", and how it makes you have confidence while developing.
Also, I really enjoyed this phrase from Kent Beck: "Partly this is because this is how I learn- I find an expert to act like, then gradually figure out what is really going on. I'm certainly not looking for the rules to be followed mechanically, although that is how the mechanically minded have interpreted them."
In Persian:
قبل از این که این کتاب رو بخونم، به تیدیدی به عنوان یک تکنیک تست کردن نگاه میکردم. از طرفی یک سری جملات و ارائههایی رو از کنت بک و سایر افراد در این خصوص دیده بودم و به شدت عاشق تفکراتش شدم.
این کتاب، به شکل خارق العادهای باعث شد تا من ذهنیتم رو در خصوص تیدیدی، اجایل و همینطور توسعه بهتر کنم. کنت بک با صحبتهای خوب و واقعگرایانهش و جوکهایی که تو متن کتاب داشت، بهم یاد داد تا چطور در خصوص این کانسپتها بهتر فکر کنم.
با خوندن این کتاب من فهمیدم که « تیدیدی یک تکنیک برای تمام فعالیتهای توسعهی نرمافزار هست » و چطور میشه با استفاده ازش اطمینان بیشتری هنگام توسعه داشت.
در کنار این توضیحات، من به شدت از این عبارت کنت بک تو کتاب لذت بردم: « این نسبتا به خاطر مدلی هست که من یاد میگیرم- من یک آدم حرفهای رو پیدا میکنم تا بتونم شبیهش رفتار کنم، بعد به مرور دستم میاد که دقیقا چه اتفاقی داره میافته. من دنبال پیدا کردن یه سری قاعده برای پیروی مکانیکال ازش نیستم، در حالی که این همون مدلی هست که آدمهای با ذهنهای مکانیکی ازش برداشت میکنن »
February 26, 2020
Neredeyse 20 yılını devirmiş olmasına rağmen TDD hakkında halen güncelliğini yitirmemiş bir kitap olarak değerli bilgiler içeriyor. Önce bir örnek üzerinden TDD’yi anlatıp sonrasında daha da ileriye giderek bir unit testing framework yazmaya başlıyor. Sonrasında da tasarım kalıpları ve işin felsefesiyle kitabı sonlandırıyor Kent. Tabi TDD ile ilgili yazılmış o kadar çok kitap ve makale var ki bazen tüm kitabı okumak yerine bu konuda iyi bir makale bulup onu mu okusam dediğim zamanlar da oldu. Yine de zamanıma değdi diyebilirim.
March 25, 2017
The book has 3 Parts - You can jump to "Part 3: Patterns for Test Driven Development" to read without reading Part 1 and Part 2.
I read this book with a friend, he and I have few notes that can share for you guys:
- Many people think TDD is a way to test: You write tests first and write code later. I have to say: You're wrong - 100% wrong.
- TDD is a way that can help you improve your performance when working, TDD can help you become a better developer. TDD is for yourself, not for your team or company.
- When you apply TDD, this means you write tests to develop your design/code.
- For example, when you develop a new feature, don't try to write the code first, and add few tests after that - that's a bad habit.
- You know why? Because you can't make sure your code is the right way and right design. And when the feature is extended, the code is messier and now I sure you won't know how to write tests to cover all cases. Trust me! I have made the same mistake in my career, more than once.
So what is the right way? The book will show you the right way you should do
For example: When you implement a new feature, don't write the code or think about design first. I highly recommend you let's think about the case and test first. How many test case that we need to write? When you have the answer then let's follow the rules:
1. Write down the test that doesn't work and perhaps doesn't even compile at first.
2. You got the error when you run the test, from the error, you will have to write code to the test pass. NOTE: You only write enough code to the test pass - Make the test work quickly.
3. Back to step 1, add one more case that you will know the test will fail. Why? Because, at the moment, you are a man that finding loopholes in the code.
4. Bang! The test fails as you expected. Now, let's think as a fixer - continue to write the code to pass tests. NOTE: Write enough code - Allow duplicated code - maximum 2 times
5. Back to step 1, add one more case that you will know the test will fail.
6. Continue to write enough code to test pass.
7. When you feel you covered all cases that you think before you start then let's jump to this step. Remove the duplicated code - refactor to code looks better.
Conclusion:
- You guys should read this book if you want to be a better developer. Each chapter and even Preface, you guys will see awesome ideas about TDD.
If you guys are looking for an example after reading this book, let's read my friend blog: https://duykhoa.github.io/katas/2016-.... He applied TDD to solve katas.
- After finish this book, you guys should read one more book: https://www.amazon.com/Growing-Object... to can understand more about TDD.
I read this book with a friend, he and I have few notes that can share for you guys:
- Many people think TDD is a way to test: You write tests first and write code later. I have to say: You're wrong - 100% wrong.
- TDD is a way that can help you improve your performance when working, TDD can help you become a better developer. TDD is for yourself, not for your team or company.
- When you apply TDD, this means you write tests to develop your design/code.
- For example, when you develop a new feature, don't try to write the code first, and add few tests after that - that's a bad habit.
- You know why? Because you can't make sure your code is the right way and right design. And when the feature is extended, the code is messier and now I sure you won't know how to write tests to cover all cases. Trust me! I have made the same mistake in my career, more than once.
So what is the right way? The book will show you the right way you should do
For example: When you implement a new feature, don't write the code or think about design first. I highly recommend you let's think about the case and test first. How many test case that we need to write? When you have the answer then let's follow the rules:
1. Write down the test that doesn't work and perhaps doesn't even compile at first.
2. You got the error when you run the test, from the error, you will have to write code to the test pass. NOTE: You only write enough code to the test pass - Make the test work quickly.
3. Back to step 1, add one more case that you will know the test will fail. Why? Because, at the moment, you are a man that finding loopholes in the code.
4. Bang! The test fails as you expected. Now, let's think as a fixer - continue to write the code to pass tests. NOTE: Write enough code - Allow duplicated code - maximum 2 times
5. Back to step 1, add one more case that you will know the test will fail.
6. Continue to write enough code to test pass.
7. When you feel you covered all cases that you think before you start then let's jump to this step. Remove the duplicated code - refactor to code looks better.
Conclusion:
- You guys should read this book if you want to be a better developer. Each chapter and even Preface, you guys will see awesome ideas about TDD.
If you guys are looking for an example after reading this book, let's read my friend blog: https://duykhoa.github.io/katas/2016-.... He applied TDD to solve katas.
- After finish this book, you guys should read one more book: https://www.amazon.com/Growing-Object... to can understand more about TDD.
March 8, 2012
Such a wonderfully written book on Test-Driven Development (TDD). It walks through several easy-to-follow examples, and then wraps up with a nice discussion of TDD and some of the patterns that show up during this style of development. This book is a breeze to read, and very enlightening. I'm so tired of ugly code that breaks all the time, so I was hoping to be persuaded that TDD really is the best way to "write clean code that works." This book definitely persuaded me.
The surprising thing was how FUN this book was to read. The author was constantly cracking me up, without wasting too many words on jokes, sounding dorky, or dumbing it down. He just has a writing style that made learning TDD fun and easy.
Here's a good example: "Write the tests you wish you had. If you don't, you will eventually break something while refactoring. Then you'll get bad feelings about refactoring and stop doing it so much. Then your designs will deteriorate. You'll be fired. Your dog will leave you. You will stop paying attention to your nutrition. Your teeth will go bad. So, to keep your teeth healthy, retroactively test before refactoring."
The whole book reads like that!
The surprising thing was how FUN this book was to read. The author was constantly cracking me up, without wasting too many words on jokes, sounding dorky, or dumbing it down. He just has a writing style that made learning TDD fun and easy.
Here's a good example: "Write the tests you wish you had. If you don't, you will eventually break something while refactoring. Then you'll get bad feelings about refactoring and stop doing it so much. Then your designs will deteriorate. You'll be fired. Your dog will leave you. You will stop paying attention to your nutrition. Your teeth will go bad. So, to keep your teeth healthy, retroactively test before refactoring."
The whole book reads like that!
May 19, 2016
This is a good introduction to test driven development, and this book helped me better understand what TDD really is. In particular the points about breaking things down to small steps, refactoring, and always working quickly to a green bar were very helpful. I did find some weird problems with the python example, which might be due to the fact I decided to go with Python3, and the book used Python2. Specifically, I was working through the examples, and found that when I deliberately went off script, and tried to make a particular test fail with a code change, it continued to be green. It turned out that the Python assert wasn't behaving the way I expected, and that left me with no confidence that the code was actually working as intended. This was after my third run through on that section, so I didn't finish the final portion. I may go back and try it again with a different language as a personal exercise, cause I do want to get through the test suite section.
March 26, 2020
The examples provide an easy to understand guide for how to follow this process. Too early to say how it works for me, but it did provide some eye opening ways of looking at things. The main downside was that the short code snippets make it difficult to see how the whole system is looking.
July 7, 2019
Carticica a fost la fel de usoara si de eficienta precum TDD si o pot considra ca o noua aditie la colectia de carti tehnice care sunt amuzant de citit. Dincolo de umorul autorului care presara si infrumuseteaza explicatiile asupra TDD, mi-a placut modul cum a fost structurata cartea si, in special, capitolele cu exemple. In aceste capitole avem un requirement care trebuie implementat. Requirementul este despicat in mai multe test case-uri care sunt notate pe o lista. In fiecare subcapitol un test este implementat si, prin urmare, o parte din cod si din logica, apoi testul e bifat de pe lista, un mic rezumat e prezentat cu ce s-a realizat datorita testului si cateva vorbe despre ce se propune in următorul subcapitol.
Acest mod foarte pedagogic de a explica ideea centrala a TDD prin exemplificare a fost nu numai interesanta, dar a si funcționat. Iar multumita alegerii lui Kent de a coda folosind Pyhon am si degustat o mostra din acest limbaj pe care imi doresc sa il invat cat de curand.
Adevarul este ca m-a convins. Desi si pana acum scriam teste pentru functionalitatile noi, mereu o faceam la sfarsit, dupa ce logica a fost deja implementata. Insa de cand am inceput sa citesc cartea, mi-am propus sa adopt principiul "nu adauga nicio linie de cod noua fara sa ai prima data un test care esueaza". Si trebuie sa recunosc ca e satisfactor intreg procesul: in primul rand pentu ca scrii prima data partea care inainte era cea mai grea sau cea mai plictisitoare: unit testul; in al doilea rand, pentru ca scriind prima data testul, te gandesti automat cum sa despici problema in pasi simpli ca sa poti scrie acel prim test; apoi esti purtata de la sine spre a te gandi la tot felul de cazuri pe care le poti testa si acoperi; apoi faptul ca ai deja o lista de teste care reprezinta toate cerintele te ajuta sa refactorizezi codul mult mai relaxat si mai indraznet; si, nu in ultimul rand, e o senzatie extrem de satisfacatoare cand adaugi liniile de cod care fac sa treaca acel test sau cand la final poti sa ai un clean code care sa te satisfca si care, in plus, face ca toate testele sa treaca.
Cred ca TDD se pliaza pe modul cum funtioneaza creierul: avand rezultate imediate care declanseaza sistemul de recompensa al creierului. Incepi sa devii dependent de endorfinele care sunt declansate de culoarea verde a testelor care trec. Ceea ce nu e rau, ci, asa cum spune si Kent, esti prins intr-un ciclu pozitiv care te impinge sa scrii cod care functioneaza si care e curat si ordonat.
O carticica scurta, amuzanta si extrem de folositoare.O recomand cu tot entuziasmul!
Acest mod foarte pedagogic de a explica ideea centrala a TDD prin exemplificare a fost nu numai interesanta, dar a si funcționat. Iar multumita alegerii lui Kent de a coda folosind Pyhon am si degustat o mostra din acest limbaj pe care imi doresc sa il invat cat de curand.
Adevarul este ca m-a convins. Desi si pana acum scriam teste pentru functionalitatile noi, mereu o faceam la sfarsit, dupa ce logica a fost deja implementata. Insa de cand am inceput sa citesc cartea, mi-am propus sa adopt principiul "nu adauga nicio linie de cod noua fara sa ai prima data un test care esueaza". Si trebuie sa recunosc ca e satisfactor intreg procesul: in primul rand pentu ca scrii prima data partea care inainte era cea mai grea sau cea mai plictisitoare: unit testul; in al doilea rand, pentru ca scriind prima data testul, te gandesti automat cum sa despici problema in pasi simpli ca sa poti scrie acel prim test; apoi esti purtata de la sine spre a te gandi la tot felul de cazuri pe care le poti testa si acoperi; apoi faptul ca ai deja o lista de teste care reprezinta toate cerintele te ajuta sa refactorizezi codul mult mai relaxat si mai indraznet; si, nu in ultimul rand, e o senzatie extrem de satisfacatoare cand adaugi liniile de cod care fac sa treaca acel test sau cand la final poti sa ai un clean code care sa te satisfca si care, in plus, face ca toate testele sa treaca.
Cred ca TDD se pliaza pe modul cum funtioneaza creierul: avand rezultate imediate care declanseaza sistemul de recompensa al creierului. Incepi sa devii dependent de endorfinele care sunt declansate de culoarea verde a testelor care trec. Ceea ce nu e rau, ci, asa cum spune si Kent, esti prins intr-un ciclu pozitiv care te impinge sa scrii cod care functioneaza si care e curat si ordonat.
O carticica scurta, amuzanta si extrem de folositoare.O recomand cu tot entuziasmul!
September 8, 2019
There are only two books you need to read to fall in love with TDD – this book and Growing Object-Oriented Software Guided by Tests. Whereas GOOS is more practical and showing how to test-drive real applications, Kent's book makes you – the reader – feel the rhythm of TDD. It's like pairing together with Kent. The book also covers non-technical aspects of TDD, such as developer's happiness and productivity.
July 20, 2020
Surely one the best way to really discover and understand TDD.
It's mainly 3 main parts : one is a very didactic introduction around a Money domain object, the second one is an impressive how to re-implement xUnit the main tool used to do test in TDD, the third one is a list of TDD pattern (from design pattern to refactoring).
Overall it's a very practical, by example and deep way to discover TDD by one of its best promoter.
It's mainly 3 main parts : one is a very didactic introduction around a Money domain object, the second one is an impressive how to re-implement xUnit the main tool used to do test in TDD, the third one is a list of TDD pattern (from design pattern to refactoring).
Overall it's a very practical, by example and deep way to discover TDD by one of its best promoter.
July 31, 2021
Simple and direct. A great read for people new to software testing!
May 28, 2020
Perfect book as a guide to start and improve TDD skills and also improve as a software engineer
December 9, 2020
Boring book. Read it from start to finish, didn't find anything I didn't know.
May 10, 2010
This fairly slim tome is overflowing with useful information from the 2 worked examples of real-world problems being solved by the author (Kent Beck, of XP and Smalltalk fame, among other things) using Test Driven Development.
The book starts with TDD being applied to the problem of doing multi-currency conversions with given exchange rates. Kent Beck does a chapter per test and associated refactoring, and this leads to extremely short chapters but where almost the entire chapter is useful information (no unnecessary recap of previous chapters or looks at topics in future chapters here). The point that comes across from the book is of a ruthless elimination of any duplication being the driving force behind this particular brand of software development. This even goes as far as removing duplication between the test-code and the application code (which provides a way to implement functionality from an initially faked test implementation without having to add unnecessary duplication in tests).
The second example is one of interest as well, where Kent Beck shows how to 'bootstrap' a testing framework using TDD, with the testing framework (a Python framework following the xUnit style) being tested by itself after an initial bootstrapping process to get things started. This demonstrates the versatility of the TDD approach and follows roughly the same style as the previous chapter.
The key principle of the book is the 'red/green/refactor' process of development, and that Kent Beck's desire is to write a failing test (only a single one at a time, apart from in certain circumstances), to get it working *as quickly as possible* (and breaking any established conventions as required) and to then remove any and all duplication in the refactoring process without breaking any tests. The results speak for themselves, as the code produced by the rigorous application of these principles in the book is extremely clean and easy to understand.
The author admits throughout that the process in use is somewhat exaggerated, but that is because the tiny steps being taken are at the level you *should* be able to work at (even if you take larger steps at time). I think of this as very much like practicing a martial art - you perform the art with very much exaggerated moves in order to get the moves second-nature. Then when it comes to using it in reality, the moves are performed much more naturally and with almost no conscious intervention, and so it goes with TDD.
To my mind, this is an essential read for any software developer. It provides concrete examples for TDD (although at a finer granularity of step than may normally be used), which is something that can be lacking in many other works on the subject. You can't read this book and become an instant master at test driven development (there isn't any book that can manage that). What this particular book provides is more important - it shows you what you should be doing in order to eventually become that master.
The book starts with TDD being applied to the problem of doing multi-currency conversions with given exchange rates. Kent Beck does a chapter per test and associated refactoring, and this leads to extremely short chapters but where almost the entire chapter is useful information (no unnecessary recap of previous chapters or looks at topics in future chapters here). The point that comes across from the book is of a ruthless elimination of any duplication being the driving force behind this particular brand of software development. This even goes as far as removing duplication between the test-code and the application code (which provides a way to implement functionality from an initially faked test implementation without having to add unnecessary duplication in tests).
The second example is one of interest as well, where Kent Beck shows how to 'bootstrap' a testing framework using TDD, with the testing framework (a Python framework following the xUnit style) being tested by itself after an initial bootstrapping process to get things started. This demonstrates the versatility of the TDD approach and follows roughly the same style as the previous chapter.
The key principle of the book is the 'red/green/refactor' process of development, and that Kent Beck's desire is to write a failing test (only a single one at a time, apart from in certain circumstances), to get it working *as quickly as possible* (and breaking any established conventions as required) and to then remove any and all duplication in the refactoring process without breaking any tests. The results speak for themselves, as the code produced by the rigorous application of these principles in the book is extremely clean and easy to understand.
The author admits throughout that the process in use is somewhat exaggerated, but that is because the tiny steps being taken are at the level you *should* be able to work at (even if you take larger steps at time). I think of this as very much like practicing a martial art - you perform the art with very much exaggerated moves in order to get the moves second-nature. Then when it comes to using it in reality, the moves are performed much more naturally and with almost no conscious intervention, and so it goes with TDD.
To my mind, this is an essential read for any software developer. It provides concrete examples for TDD (although at a finer granularity of step than may normally be used), which is something that can be lacking in many other works on the subject. You can't read this book and become an instant master at test driven development (there isn't any book that can manage that). What this particular book provides is more important - it shows you what you should be doing in order to eventually become that master.
February 11, 2012
I must have read this back when it came out because I remember some of the jokes. This is a fascinating book about TDD, esp. if you read it now, given the maturation of the development model. On p. 199 there is a tantalizing section on "Application" TDD, where in a paragraph Beck anticipates BDD -- and how hard BDD can be if you don't properly rope in stakeholders as collaborators. I don't think we've figured that one out yet.
The book is a weird mix. First there's a section where Beck uses TDD to evolve an interface for handling money operations in different currencies. The section is a bit of a cheat, though, because first off Beck notes that he's done the "money" implementation 3 times in production, six times in print, and in live talks (p. 82): So the notion that he is somehow figuring out a problem or design with his TDD is pretty doubtful. He also notes in passing as he is working towards an implementation of a Sum class that it looks like a Composite pattern (p. 74) . . . that's right. He basically had the whole architecture in his head and is just kind of playing around. The section is also problematic because there's no complete source listing of the end product. Nowadays, it would be nice to have a full-blown commit list in github. On the other hand, it's all Java, and you have to wonder if it would take so long in, say, Ruby or Python.
Then there's a section on TDD'ing a Python xUnit. This section is quite forgettable. It's supposed to be "meta" and show you how you can TDD anything, but, really, it's pretty boring.
Then comes Part III: TDD Patterns. This bears close reading and has lots of little bits of advice, but you had better already be a "patterns" person. There are some interesting bits that show how far we've come from Java (for example: I can't imagine every doing a "self shunt" (p. 145) in Ruby.
We have really come a long way.
So: I recommend this for wisdom and for remembering the history. But if you're new to TDD I'm not sure this is the right place to start anymore.
The book is a weird mix. First there's a section where Beck uses TDD to evolve an interface for handling money operations in different currencies. The section is a bit of a cheat, though, because first off Beck notes that he's done the "money" implementation 3 times in production, six times in print, and in live talks (p. 82): So the notion that he is somehow figuring out a problem or design with his TDD is pretty doubtful. He also notes in passing as he is working towards an implementation of a Sum class that it looks like a Composite pattern (p. 74) . . . that's right. He basically had the whole architecture in his head and is just kind of playing around. The section is also problematic because there's no complete source listing of the end product. Nowadays, it would be nice to have a full-blown commit list in github. On the other hand, it's all Java, and you have to wonder if it would take so long in, say, Ruby or Python.
Then there's a section on TDD'ing a Python xUnit. This section is quite forgettable. It's supposed to be "meta" and show you how you can TDD anything, but, really, it's pretty boring.
Then comes Part III: TDD Patterns. This bears close reading and has lots of little bits of advice, but you had better already be a "patterns" person. There are some interesting bits that show how far we've come from Java (for example: I can't imagine every doing a "self shunt" (p. 145) in Ruby.
We have really come a long way.
So: I recommend this for wisdom and for remembering the history. But if you're new to TDD I'm not sure this is the right place to start anymore.
August 5, 2018
I am very amused how much people loves this book. It describes approach to TDD, but from my perspective (after couple years of development practice) done in completely wrong way. In the first part we are observing how author wrote code and refactor its. With the new requirements he adds functionality. At the beginning he just copy the code, and than refactor. My experience tells: no way. In complicated projects the final result of the application will be application with duplication. Of course anybody can said, yes if you finished like this you made it wrong. But this is how development works...
Also in the second part of the book. Some design patterns are described but it is completely useless. Patterns are described on one page, so for people which know how to use them it is not necessary and for people which doesn't know it wont give a clue how to work with it.
Additionaly author try to be cool and talk with the reader. I don't like it. I perfectly know that I am reading book and he do not have to try to make it like phone conversation.
Also in the second part of the book. Some design patterns are described but it is completely useless. Patterns are described on one page, so for people which know how to use them it is not necessary and for people which doesn't know it wont give a clue how to work with it.
Additionaly author try to be cool and talk with the reader. I don't like it. I perfectly know that I am reading book and he do not have to try to make it like phone conversation.
October 20, 2013
Brilliantly done, it's given me a lot to think of in terms of programming.
A bit too abstract in some points (thus the 4 star rating), but i guess a revised version with a bit more examples and less abstraction would get a 5 star rating.
A bit too abstract in some points (thus the 4 star rating), but i guess a revised version with a bit more examples and less abstraction would get a 5 star rating.
January 25, 2011
I haven't actually read the whole thing, but the first half was pretty amazing. I generally have a hard time with tech books, which is why I probably won't actually finish the book. :)
October 16, 2014
Uma boa introdução ao desenvolvimento orientado a testes, com um exemplo bem interessante e uma didática bem simples de entender, recomendado pra quem está iniciando.
December 4, 2014
Very detailed walkthrough of TDD, but quite basic stuff.
February 5, 2017
Good to know Java and Python beforehand as the 2 examples are written in those languages. Decent read.
November 14, 2017
Still relevant but first part should be a tutorial video and not in a book.
July 3, 2018
As my first real dive into test driven development, this book was a great introduction into the practices and the habits that are involved. The one thing that I wish I had done when I started reading is actually trying to implement the examples that are in the book, as I think the practical side would have helped the examples sink in a little bit more.
Saying that, I learn really well from books, and I had no trouble following the code examples from one to another and having the changes written in such small steps certainly helped.
Beck’s explanations were great to help the concepts really solidify and he had a writing style that made the book much more fun to read than I expected it to be.
I understand that to most people, TDD is not complicated, it’s just habit, but having never done it before and not having come from an environment where time is given to testing, this book was a great way to learn what I should have been doing all along. And being able to put some of the techniques into practice at work has been great, I think that’s what will really cement the knowledge for me.
Posted on: http://emmaloui.se/2018/07/03/kent-be...
Saying that, I learn really well from books, and I had no trouble following the code examples from one to another and having the changes written in such small steps certainly helped.
Beck’s explanations were great to help the concepts really solidify and he had a writing style that made the book much more fun to read than I expected it to be.
“Write the tests you wish you had. If you don’t, you will eventually break something while refactoring. Then you’ll get bad feelings about refactoring and stop doing it so much. Then your designs will deteriorate. You’ll be fired. Your dog will leave you. You will stop paying attention to your nutrition. Your teeth will go bad. So, to keep your teeth healthy, retroactively test before refactoring.”
I understand that to most people, TDD is not complicated, it’s just habit, but having never done it before and not having come from an environment where time is given to testing, this book was a great way to learn what I should have been doing all along. And being able to put some of the techniques into practice at work has been great, I think that’s what will really cement the knowledge for me.
Posted on: http://emmaloui.se/2018/07/03/kent-be...
April 3, 2020
I'm a fan of 'clean code that works' as they say it. Recently, projects became too large to handle just with 'clean code' (it's apparently the title of a book by Robert Martin), so I was looking for ways to add '... that works' to my 'clean code'. Testing was naturally the next step.
I'm happy to say I picked the right book. Kent is an expert programmer (he's also the author of 'Extreme Programming' which I'm going to read soon but should have read before this). His explanations are very clear and concise, no beating the bush. He's also funny which makes you feel like your buddy is explaining this stuff which is good because programming books can sometimes get too boring. He also shares a lot of personal comments on topics and design decisions that are not exactly well understood.
Regarding content, all major topics that I could find online are covered in the book. At some places, more examples could've helped. I was following Python's 'unittest' documentation while reading the book which was really helpful and I recommend that you find the corresponding library for your favorite programming language and follow along.
I highly recommend this book if you're into large software/programming projects or are expecting/wanting to join one soon. It's an amusing book and you'll have a good time.
I'm happy to say I picked the right book. Kent is an expert programmer (he's also the author of 'Extreme Programming' which I'm going to read soon but should have read before this). His explanations are very clear and concise, no beating the bush. He's also funny which makes you feel like your buddy is explaining this stuff which is good because programming books can sometimes get too boring. He also shares a lot of personal comments on topics and design decisions that are not exactly well understood.
Regarding content, all major topics that I could find online are covered in the book. At some places, more examples could've helped. I was following Python's 'unittest' documentation while reading the book which was really helpful and I recommend that you find the corresponding library for your favorite programming language and follow along.
I highly recommend this book if you're into large software/programming projects or are expecting/wanting to join one soon. It's an amusing book and you'll have a good time.
August 23, 2022
A brilliant, careful way to design software. I wish I had read this much sooner. I had previously learned TDD at my bootcamp, supplemented with a few online resources, but this book cleared up a lot of issues I had been having.
For example, up to now I had only ever used the Triangulation style of TDD, where you only generalise code when you have multiple examples (i.e. multiple tests for the same behaviour), but now I know that this is the most conservative strategy. Instead I can use Fake It (then refactor) or Obvious Implementation to quickly get to green when I don't feel the need to be so careful.
Because I had previously only used Triangulation, I also misunderstood the refactoring step slightly. Beck's explanation of this step as removing duplication, including between the code and the tests, cleared things up for me. For example, when you have a test to check a method returns 1 with some input, and you hard code return 1 into the method, there is duplication between the test and the code. You can refactor this to use variables instead of constants in order to remove duplication, with no need to triangulate and add a test for returning 2.
I've also learned that my definition of a "single change" is much bigger than Beck's definition, and I can now take much smaller steps when I need to.
For example, up to now I had only ever used the Triangulation style of TDD, where you only generalise code when you have multiple examples (i.e. multiple tests for the same behaviour), but now I know that this is the most conservative strategy. Instead I can use Fake It (then refactor) or Obvious Implementation to quickly get to green when I don't feel the need to be so careful.
Because I had previously only used Triangulation, I also misunderstood the refactoring step slightly. Beck's explanation of this step as removing duplication, including between the code and the tests, cleared things up for me. For example, when you have a test to check a method returns 1 with some input, and you hard code return 1 into the method, there is duplication between the test and the code. You can refactor this to use variables instead of constants in order to remove duplication, with no need to triangulate and add a test for returning 2.
I've also learned that my definition of a "single change" is much bigger than Beck's definition, and I can now take much smaller steps when I need to.
Displaying 1 - 30 of 208 reviews