CU.NET: Test Driven Development with Robert C. Martin (Uncle Bob)

there okay so we're going to do a talk on test-driven development pretty much yep good what do you know about this turbine good yes excellent is anybody done it very I get more so you can raise your hands if you've done pestering the relevant raise your hand I can see you all oh okay so casterman development what's the devil is this is an old discipline it's been around now for probably 15 years it's actually older than that but it really became popular about 15 years ago when the agile movement started it is a discipline and like all disciplines it is arbitrary there are parts of it that you may feel make no sense that's okay it's just an arbitrary discipline so for example surgeons will wash their hands before they operate and they have a discipline for this they will they will go into the operating room the scrub room and they'll get a brush and they will do ten strokes across the finger right and then ten strokes across the top of the finger and then ten strokes across the side and then ten strokes across the face and ten strokes across the nail and then they do the next finger is ten the right number and I don't know you know it would eight suffice mate should it be twelve maybe doesn't matter it's arbitrage a discipline a ritual so you can expect to feel that way about test-driven development as well it's an arbitrary discipline but the thing about a discipline is is that once you decide to follow it you follow it whether it's arbitrary or not it becomes something in green then you follow almost all the time so what are these disciplines what is the rule of test-driven development so I can show to you here slide and you see all that slide yeah everybody see it yep good okay the three laws of test-driven development down into these three laws a long time ago the first one is immediately difficult to understand you are not allowed to write any production code unless it is to make a failing unit past past now right away this sounds Google right because what are you in a test there's no production code written yet okay you can't write the production code until you have a failing unit test which means you have to write the unit test before you write the code and what are you going to test the fish no codes but it makes no sense at first but don't worry about that because the second law is worse the second law is you are not allowed to write more of a unit test than is sufficient to fail and compilation failures are failures which means that you can start out to write a unit test but within a line or two it's not going to compile because you're calling something that you haven't written yet and so you'll have to stop right in the unit that you can't finish it and you'll have to start writing production code and then the third law is the worst of them all it's this that you're not allowed to write more production code then is sufficient to pass the currently failing test if you um if you think about this these three laws I'll lock you into a cycle that is five seconds long ten seconds you will know that you want to write some code but you can't because you have to write a unit test so you start to write the unit test but after writing a line of it you have to stop because it doesn't compile so then you have to start writing production code but after writing a line of it you have to stop because that makes the test compile so then you have to write another line of the unit test but that fails and then you have to write another line of production code and that makes it Pat and you go back and forth between these two screens of code on a almost 5 seconds or 10 seconds cycle time now if you're a programmer of any experience that just sounds stupid why would you do this it would be boring it would be dull it would be tedious you would never be able to sink through an if statement without interrupting yourself and writing a test app way through it you'd never be able to think through a while loop without interrupting yourself in fact you're just constantly interrupting yourself adding a little test a little code little test little code and why would you do this makes no sense to the normal programmer this makes but there had to be a bug right but imagine a group of people like you in a room like you have at the moment all following these three laws pick one of those people doesn't matter Booga let her win everything they were working on executed and passed its tests sometime in the last few minutes probably sometime in the last one minute and it doesn't matter who you pick and it doesn't matter when you pick them everything worked a minute what would your life be like if a minute ago everything worked is how much debugging do you think you do there's not a lot of debugging to do if everything worked a minute how many of you are good at the debugger you know the debugger the debugger is your is your tool you know all the hotkeys you know how to to step into and step over and set watch points and breakpoints and you can you can set a breakpoint here and get to it three times and then get it to another breakpoint six more times and then wait for this variable to be a 37 and then really debug this is not a skill to be desired you don't want to be good at the debugger the only way you get to the debugger is to spend a lot of time debugging and I don't want you to bug me when you are following these three laws there's hardly any reason to debug anything because everything worked a minute ago not I'm not saying that you don't get but you do it's still software it's still hard there are still weirdo bugs that but they happen much less frequent because most of the time everything worked a minute ago so the most common debugging technique is to hit ctrl-v enough times to undo what you last did that broke something and then to retype the line of code that broken there's hardly any thought process for debugging that may make some of you a little bit anxious because you like to debug but believe me it's a it's a habit you can get over pretty quickly so um I could say that following these three laws would with them shorten your debug time by half but never mind that that's not the issue there's another issue how many of you have integrated a third-party package Oh see I can see your hands isn't it good yes and and you've integrated a third-party package where did you get the package from well maybe you downloaded it from the internet or or maybe you got a DVD back in the old days and inside this third-party package there's some dll's there's some source code there's some jar files there's also probably a PDF and that PDF contains an ugly appendix and that ugly appendix contain all the example code where's the first place can you go you don't want to read the manual the PDF manual decoration is that you go right to the appendix you go right to the example code and you read the example code because the example code will tell you the truth when you write unit tests according to these three laws what you are writing are the example code for the whole system the colored examples for everything you're doing you want to know how to create an object there is a unit that creates that object every way it can be created you want to know how to call some API function there is a unit test that calls that API function every way it can be called and these unit tests are snippets of code they're all independent from each other they don't make a system so they're not complicated anybody who's a programmer can read them they're written in a language you understand they are so formal they execute they are absolutely unambiguous and they cannot get out of sync with the system they are the perfect kind of documentation before am for a software system documentation written in code that describes the system there's no joke it's a joke about agile software development goes like this we're doing agile development oh that's pretty cool that means you must be you must be working in pairs oh no we're not working on pairs well well then you must be you must be working in really short cycles no no no we don't work in short time well well then you must be writing lots and lots of tests no we're not doing anything well then why do you say you're doing agile development we've decided not to write any documentation this is the the old old joke that used to be told fairly frequently about agile software development but it is a misinterpretation of what agile is about because we do write documentation agile software developers write documentation but they write the best kind of documentation they write code the document so if you um if you follow these three laws you can shorten your debug time and you get this sum this stream of documentation which is almost perfect documentation for a complicated system but set that aside because there's something else how many of you out there have written unit tests after the fact yeah and thought you were doing test-driven development um how much fun is this much fun why isn't it fun why isn't it fun right unit test and the answer to that is it's not fun because you already know the code works you've tested it manually you didn't need to write the unit test to prove to yourself you wrote the code already you tested it manually you've seen it on the screen and now after all of that somebody wants you to write unit tests and that of course sounds like a bunch of make work some process weenie up there and told you you had to add the right unit tests and guilted you into it and so so out of guilty writing unit tests and another one and it's boring and then inevitably you will come to the test that's hard to write it's hard to write because the code you wrote was not written to be testable or at least you didn't make a testable enough it's two coupled just something it's and to break that coupling and write that test would be hard and you look at it and go oh man they have to spend twenty minutes messing around with this and then you think but I already know it worked as I tested it manually why do I need to write this test let me walk away and you leave a hole in the test world and you know if you're doing that everybody else's - leaving holes in the best way when you um when you follow the three laws something else happens you can't write production code that's hard because you write the test first time and because you've written the test first you design the production code to be testable and another word for testable is decoupled simply by writing the test first you wind up the coupling the production code in ways that you had never thought about before you wind up with a better design but more than that it's fun it's fun because the test fails and now you get to make it pass how many of you became programmers because you've got some code to run once and you want that feeling again you remember a long long ago maybe you went into a Kmart or something and there was a Commodore 64 or a trs-80 or some personal computer on the shelf and you walked up to it and you wrote a basic program to printed your name a million times and you reek and you knew suddenly that you have the power you were the master the Dominator of that computer you could make it do anything and you want that feeling again this is what the test driven development helps you with you get to write a test and then make it pass and that feels good and then you write another test and you make it pass and that feels good and you get that excitement again of what programming is supposed to be like if you follow these three laws you can reduce your debug time you get great documentation that your design improves it's fun and none of that is why we do it don't forget all of that why do we do test-driven development really how many of you have been significantly impeded by bad code okay so that's everybody good why did you write it now you know it's going to slow you down you've been significantly impeded by bad code everybody knows if there's bad code it's going to slow us down why do we write the bad cop well there's lots of excuses for this right we write the bad code because pretty much because we have to go fast I'll leave you to deal with the logical inconsistency of writing bad code that slows you down in order to go fast but let me ask you a different question why don't you clean it when's the last time you brought some code up on your screen and you looked at it and thought no I should clean this and your very next thought is I'm not touching it because you know if you touch it you will break it and if you break it you will own it until you walk away from the cup that's going to be the one to groom this code because I don't want to own it this is a fear reaction where reacting in fear from the code that you used to dominate that code that thing that you've created no longer submit your will you submit to it you have become afraid of it it dominates you and I submit to you this if you are afraid to clean the code then you never will clean it the code will simply get worse and worse and worse over time slowing you down slowing everybody down slowing the whole team down grinding everyone into slower and slower and harder and harder work making the system virtually impossible to deal with this is the only thing that can happen if you are not willing to clean the code we are not willing to do the one thing that might improve things because we're afraid how do we get rid of that fear well imagine that you have a button and you can push that button anytime you want and some lights blink and some cute computer noises come out of your laptop and within a few seconds of the green light lights up and that green light tells you that everything works the whole system works and you believe it if you've got a button you can push and it tells you that everything works that changes everything you will go to your laptop you will bring code up on your screen you will say oh this is ugly I should clean it and the fear is gone you will push the button and it will turn green and then you will make a small change to the code you will you will change the name of one variable and you'll push the button and it will go green and then you'll say hmmm that that's fun there is too large I think I'll split it into two functions and you'll push the button and it will go green and you'll say to yourself well that new function I just created I could move it into another class and you will push the button and it'll go red and you'll put the function back where push the button and it'll go green and then you'll move it a different way and it'll go green if you have that button you're not afraid to clean the code if you're not afraid to clean the code you will clean the code if you clean the code the code will get cleaner and as the code gets cleaner everybody goes faster this is why we do test-driven development I'm the documentation the better design the fun all of that stuff is extra the real reason we do test-driven development is to get rid of the fear and keep control over the code imagine how wildly irresponsible it is to be afraid of the code that you've created to be so bound by it that you refuse to do even the slightest little thing that might improve it how incredibly unprofessional and a suite of tests solves that problem whoo well it solves the problem if you trust the suite of tests if you don't trust the suite of tests if the if the green light goes on and you look at it in your scoff at it and you say yeah yeah but I know there's still problems in there then that suite of tests is doing you no good at all it does you no good to have a suite of tests that you don't trust you don't trust the suite of tests you might as well throw them away they're not telling you anything it is worthless to have a suite of tests that tests half the system it is worthless to have a suite of tests that tests 80% of the system because there's no decision that you can make based on the outcome of those tests you're still going to react with fear the only way to have a suite of tests actually mean something is if you trust in something if it tests everything and that brings us to the three laws as if you follow those three laws you're going to have tests to test everything there's ever anybody ever run a code coverage tool yeah yeah the guy who's raising his hand outside of the camera did um what's a good code coverage target what percentage of the lines of code should be covered by your test 100% hundred percent it's the only meaningful number and the other number is meaningless there's no point in having a goal of 60 percent ooh we've got 60 percent coverage aren't we cool there's no point in having that goal there's no point in having a goal of 80 percent coverage it doesn't tell you anything the only thing that tells you something about 100 percent coverage so that's the goal it's a goal you can't reach by the way it's an asymptotic goal but it's one of those goals that you keep on trying and trying to reach and getting ever closer and closer never quiet ever getting there because it's a very hard goal to achieve but you get so close that you trust the sweet of death but enough of the preaching by the way who else does this who else what other profession does something like driven development is it what other what other profession manipulates symbols the way we do and has the issue that every one of those symbols has to be right you may use the right source code on a screen every one of the characters on that source code on that screen has to be the right character a single character wrong can corrupt the whole system better yet you could compile your code down into a binary give me that binary on ax I'm a thumb drive I could reach into that thumb drive and find a single bit and flip that bit and make your system worthless I can bring any systems to its knees by flipping just the right fit we software developers we work in an environment where a single bit can cause a failure who else has that kind of problem and the answer to that is accountants accountants deal with these bizarre symbols that they write down on spreadsheets they're called numbers these symbols and they have to put just the right numbers in just the right places and it has to be just perfect and if they make a single-digit error just the right time then the whole company goes under and all the executives go to jail we've seen that happen how do you accountants prevent that from happening and the answer to that is they have a discipline if the discipline that was invented 500 years ago called double-entry bookkeeping they enter every transaction twice transaction once it's on the liability side once on the asset side those two follows separate mathematical pathways until they wind up at a subtraction on the balance sheet that must yield zero and the way the accountants do it is they add a transaction on the liability side they do the sums they add the transaction on the asset side they do the sums they do the subtraction they get a zero then they add the next transaction assets liabilities sum zero then they do the next transaction as that liabilities sum zero they do not add 50 transactions to the liability side and 50 transactions to the asset side do the sum do this to the subtraction 37 for obvious reasons they don't want that 37 they want to know which transaction went wrong test-driven development is double-entry bookkeeping it's the same discipline shifted slightly for software but it's the same principle we just say everything twice once in the unit set side once on the production code side they follow complementary execution pathways and wind up at a green light or a zero as its failed or some message in both cases in both the accounting case and the programming case this is a binary result pass or fail and that's how the accountants keep their work from imploding on them we keep our work on us or at least how we should be keeping our way do accountants have deadlines new managers give them impossible schedules are they pounding desks thing we've gotta have the spreadsheets of course under pressure do the account suddenly say well okay we'll do all the liabilities we'll forget all the assets we'll do them later no they go to jail if they do that the counting has the force of law behind it double entry bookkeeping as the force of law behind it and one day probably not too long from now software disciplines will have the force of law behind them because our civilization has become far too dependent on software to allow software developers not to be regulated that regulation is coming I hope we can regulate ourselves before government regulates us for them instead of for us but enough of all this let's do a demo I am going to show you how to test driven development works can you all see my screen yeah I'm yeah good lovely alright what we're gonna do here is we're going to write a program that calculates the prime factors of an integer let me let me tell you the history of this my um my son came home from junior high school the year was probably 2006 maybe five something like that he came over to your high school he said dad got a homework problem I have to calculate the prime factors of a bunch of integers and I said to him alright son we'll go to your bedroom do the homework and when you're done with it I will have a little program written that will allow you to enter your answers and it'll tell you if you're right or not I wasn't gonna give him the answers but I'd give him a way to check the answers so he went to his bedroom he started doing his homework and then I sat at my kitchen table and I wrote an algorithm to calculate the prime factors of an integer now how would you do this and and the the answer I came up with was well if I had a list of prime numbers then I could divide my candidate number by each of those Prime's until all the all the factors have been pulled out and so I thought I thought well when I get when I have to do then is calculate a list of prime numbers and I could use a standard algorithm for that like the sieve of Eratosthenes and then I build up this array of prime numbers and then I would apply that to all the candidates so that's how I thought I was going to do it but then I said well let's do test-driven development here and I had been doing test-driven development for about five years so I was still kind of new at it and I sat at my kitchen table and I said okay all right well let's just write the first test and you can see that test right here assert that the factors of one gives us the empty list and notice that I've implemented the factors of function to return null I expect that this will fail I'm going to run the test and of course that test fails it says hey I expected an empty collection but what I got was null instead I can fix that failure pretty simple thing to fix so I'm going to return a new ArrayList of integer that ought to fix the test ah now the test passes excellent okay um next best assert that the factors of two contains two and I will need to import my contains method this should fail it does um the test the container does not contain the two how do I make this pass well to make it pass I can do is this I can take this new ArrayList and put it into a variable named factors and I'll just return it and then I'll put in this ugly if statement if n is greater than 1 then factors dot add to and that should make my test pass and it's s bus that's fast now at this point you're probably thinking yeah but you're just kind of hack that in there I mean there's no design why did you make that n greater than 1 and yeah that's exactly what I did I just kind of hacked it in there but watch what happens to this if statement what happens this is statement is fascinating in the meantime we need to try three factors of 3 and that should contain a list with nothing but a 3 in it this should fail yes it fails there was no 3 in the list what was in the list was a - well that's not right now I need to make this pass we're going to play a little game of golf you and I golf in test-driven development making the test pass with the fewest possible keystrokes how can I make this test pass with the fewest possible commute I've never had an inch today yeah look it's that house our house demolition interesting thing happened here I took a constant and converted it into a variable I generalized this shame was a generalization and that brings up something interesting about driven development what made the test fail was that line there which made the tests more specific more constraining adding more specificity to the test what made the test pass was making the production code more general this is always going to be the case as the tests get more specific the production code will get more general and we will continue this process until we have generalized a solution that passes all the tests that we can pose the next test is a simple one factors of four contains two and two those are the prime factors of four this should fail yup it fails notice how happy I am that it failed right because that's what I expected getting a failure that you expect is just as good as getting a green bar that you that you expect okay now I need to make this pass how do I make this pass um well doesn't look like there's anything really clever I can do I think what I'm going to have to do is is put another if statement in here if n mod 2 equals 0 if n is divisible by 2 then factors dot add two so if it's divisible by two I will add a two now I want to reduce n by that factor so I will say n divide equals two that will reduce n by the right factor now let's say in the case of four and we'll come through here and we'll be divisible by two so we'll put a two in the list we will divide that four by two making n 2 we will add the second two to the left and return the list that should work oh but it fails ah not the forecast it doesn't fail this test its failing this test because if n is a two we find it to be divisible by two we put the two in the list we reduce the end to a one and then we put a 1 in the list and that's wrong we never ever want to put a 1 in the list so let's put a little guard here if n is greater than 1 you can add that n but not if it's equal to 1 at this point some of you are about to just walk out of the room because this is so bad hacking this awful growing if statements in and just throwing statements in without any thought but watch what happens next notice that this if statement and that if statement are the same it's met interesting and in fact um I can take this as statement right there I can move it out of the other statement this will still pass so now I have two consecutive if statements with the same predicate and that should make you think of an unwound loop a loop that somebody tore apart into a bunch of separative stainless keep that thought in mud because we need to do 5 factors of 5 are just 5 a pass or fail oh that passes yeah cuz 5 is prime ok that's good let's try 6 that factors of 6 it contains a 2 & 3 pass or fail - cool okay that make any sense yeah because 6 is divisible by 2 leaving a 3 left over which we stick and move stick on the list so that makes it um that factors of 7 contains seven hats three in a row three in a row path as hacking as this algorithm is it's doing something right but the next test is bound to fail because nothing in our code and put three things in the list 8 is 2 cubed nope sorry now what it did find in the list was it was a 4 and that makes sense because probably what we did is we put a 2 in the list and then we put up 4 in the list we're going to play another game of golf here we're going to make this test pass in as few statements as possible few keystrokes as possible how can I make this pass in as few statements as pasta you won that loop yeah if - while fascinate all right all I did was changing it to a while and that made the test pass and that's a much more generality when you take an ifs and make it a while you've made the if more general and a while is a general form of an if and if is a degenerate form of a while so that was interesting but but we should we should do the next test now this must pass because there's nothing in our code that can put two threes in the list this must fail there's nothing can put two threes in the list it does fail all all we put in the list was a nine that's wrong okay how do we make this pass well look at here that little loop there is a little engine that can factor out twos let's sum copy it and paste it and change the twos to threes which will make this a little engine that can factor out threes and that passes ah but it broke a rule we're not allowed to do what we just did broke two rolls actually the first rule is did look at code we've got a duplication of code which is always a bad idea the second rule that we broke was this rule of making the production code more general we didn't make the production code more general we actually made it more specific if we continue down this pathway we could never finish we'd have to add a while loop for every prime number so I'm going to get rid of this but maybe what we can do is take this little loop here this little engine the factors out twos maybe we can put it in its own loop in order to do that I'm going to take this two and I'm going to turn that into a variable named uhm divisor and I'm going to take that divisor and I'm going to take it up out of that if statement and let's see I'm going to take this sum if statement here it turns out that if I continue to divide and divide and divide by prime factors I will know that I'm done when n is finally equal to 1 because I will have divided out all of its factors until n is a 1 so this if statement is just the right thing I just need to turn that into a while now I need to increment the divisor mmm where would I do that well probably here hmm pass or fail Pat's fascinating ok well that's interesting you know what this while loop cannot terminate until n is not greater than a 1 actually it's going to be equal to 1 so this is statement no longer does anything it really was the terminal condition of that unwind loop hmm that's nice still passes um we can probably improve on this a little bit like we could make this am a for loop instead of a while loop it doesn't really need an initializer but it does need a incrementer it turns out the bed incrementer is just this don't need that semicolon anymore hmm don't really need these braces anymore I'm on a mission to destroy all braces that works that's nice and the reason I'm on a mission to destroy all braces is that I'm going to work very hard to get all my while loops and if statements down to one line of code if you want to make them two lines of code you can put the damn braces in I think I can make this a four loop and that means I can probably take that and make it the initializer of that for loop and I'm going to need an increment but I happen to have one down here I don't need that semicolon really don't need that set of braces there that still pass hmm okay well that's interesting let's um try the next test let's go for a big number two times 2 times 3 times 3 times 5 times 7 times 11 times 11 times 13 that's a nice big number the factors of that big number will be 2 comma 3 comma 3 comma 3 comma 5 comma 7 comma 11 comma 11 comma 13 huh master fail I believe we're done where did that algorithm come from it came out of my brain I mean I wrote it but I did not think through the algorithm I wrote it in fact I'm not sure I've thought through the algorithm at all do we know why this works because the deaths death wow that is not good enough yeah at some point you have to let it go why is this working it's and after a while you realize well it's working because I divide through by all the twos and then I divide through by all the threes and then I divide through by fours but I've already taken out all the twos so the the force are already gone then I divide through by the 5 then I divide through by the sixes but by then all the twos and threes are gone this is the sieve of eratosthenes just twist it a little bit twisted to give me prime factors this is just about the best algorithm you can get for it you can improve it slightly by changing the the loop condition there to be the square root of n rather than one but in any case that algorithm got put together one tiny little test case at a time I sat at my kitchen table in 2005 or whatever year that was and I was astounded at what I had created I thought I was going to have 30 lines of code I thought I was going to have the sieve of eratosthenes and then some kind of weirdo division loop and instead I wound up with three lines of code and it startled me this is a standard example of test-driven development it's one of the one of the common examples I use the the little cycle you saw me go through here is very similar to what we go through when we're doing real test-driven development on really hard hard and complicated projects let's just like this and the only kind of thing I can demonstrate in a short talk like this but the real thing doesn't look any different this is what we do you write these tests we make them pass we go through them one little test case at a time I'm until everything work let me show you a bigger project this is a project with about I know 70 or 80 thousand lines of code I will run the entire test suite for you the coverage here is on the order of 95 96 % it's hard to measure because the the coverage tools can't see all the code some of the Codex kids out of process but I believe the coverage is very high in the high 90s you're looking at all the j-unit that's running now they should run in just under a minute I do an awful lot of work in here to make sure these tests run fast lots of stuff is is mocked out the database is mocked out the web servers mocked out I do anything I can to eliminate things that are slow because I need my tests to run things yes the tests don't run fast you're not going to run them so they got to run fast and you'll see these Jana tests will finish in about a minute and then it'll start running a higher level set of tests which are called acceptance tests you'll see that happen in just a second they take about another half minute and that's the entire test suite there we go now we're going to build the jar file the unit tests are done we're going to do a the jar file build and then we're going to do the acceptance tests here they go oops oops oops instead there they go those are the acceptance tests run I expect that everything will pass again this is a fairly large system maybe 70 or 80 thousand lights out it's a web-based system with a middleware layer and a persistence back in virtually every line is tested this project has been in development since 2001 we've twisted it and pleased it and turned it and done all kinds of stuff to it it's remained healthy and clean throughout its lifetime because we can go in there and clean it up anytime we need to and we do and clean it up a lot and this should be anything just about now okey-dokey two minutes five seconds I think the the WebEx software was slowing me down just a little bit usually it's a minute forty uh but that's my test suite for a fairly large system that is the end of my musical presentation are there any questions out there I have a question what about a lot of us work on kind of legacy systems or systems we didn't start from scratch and kind of sorry they're kind of big projects but they weren't let's say they didn't have any test cases both in mind how do you do test-driven development and that kind of contest you don't do test-driven development in legacy systems because they don't have any that so what you have to do instead is very gradually start getting some tests into the system this test suite that you're going to be building is going to take a very long time probably eight years to get run months at least probably years you're not going to be able to trust it because it'll be incomplete but every test you add will make things a little bit better how do you add those tests you do not start a project to put the system under test that project will fail and you'll wind up disgracing yourselves and disgracing the whole notion of test-driven development what you do instead is anytime you have to touch the legacy code for any reason you do some random act of kindness to it that allows you to begin to add a test the first the first time you touch the legacy code you might not be able to add a test it might be too hard the second time you might not be able to but you do a little bit of cleanup just enough not a lot of risky stuff change of variable names let it function in a half maybe add an interface where it's necessary do something nice that allows that moves it towards being testable at some point in that batch of code you can you can add a test and when you add the test that makes that little bit of code a little bit more robust it's easier to make even more changes to it more random acts of kindness you can add more tests and more tests very very gradually you add tests to this system slowly faithfully I follow a simple rule it's called the Boy Scout rule and it's called the Boy Scout rule because the father of the Boy Scouts left this message to them after he died he said Boy Scouts leave the world better than you found it the Boy Scouts promptly took that and changed it to leave the campground cleaner than you found it and I took it and said leave the code cleaner than you found it in fact every time you check the code in check it in cleaner than you checked it out do something simple that makes it a little bit better and then check it in never check it in worse always check it in a little better if everybody did that then the code base would just get better and better and better over time bit by bit slowly in a legacy environment you get the code to the point where you can add more and more tests there are parts of the legacy that no one ever touches no one understands no one touches it's been that way for years that stuff you will never get under test and you don't have to get it under test it works it's the other stuff the stuff that you do change relatively frequently that you manage to massage into more and more testability there's another rule anytime you must add new code to the legacy do not add the new code into the body of the legacy where it can't be tested add it into a brand new module that can be tested and then wire that into the legacy and yes that will probably take a little bit longer and yes that will make you feel uncomfortable because you're under a lot of pressure to get things done quickly but it's the only way to solve the problem of going slow not doesn't take that much longer write it in a module that is testable right at using tester of and development and then wired into the legacy code gradually bit by bit you will have more and more of those kinds of modules gradually bit by bit some of the other modules and the legacy will have become tested and then at some moment you will look at this code and say you know what I think we can pull out all this tested stuff and and surround all the untested stuff and strangle it out of existence rewrite it until it doesn't exist it hopefully you've got the that central part small enough by that time that's not necessarily good news if you've got a legacy environment you're stuck with a mess for a long time took a long time to make the mess it's going to take a long time to clean it up there's no magic bullet there but don't make the mess worse don't continue to propagate the problem start gradually to clean it as anybody read Michael feathers book on this topic working effectively with legacy code working effectively with legacy code let me get that share my screen and I'll show you that book now I need you guys to have it look you haven't read it just right here yeah see my Christmas tree yeah yeah okay there's the book working effective with you like I said Michael feathers this will be the most depressing book you will read lots of really great ideas and lots of clever ways to help you get the system under test but it will also make it very clear that it is not an easy task there's no simple solution anybody else with a question looks like no more question oh I see you I see getting pressured by getting it done in a certain time frame on a certain amount of money yeah I I took it as a discipline I said to myself you know I've been programming for a very very long time I'm I'm 62 years old I wrote my first program when I was clever so I've been programming for Hamilton um and at some point in roughly 1999 I saw this discipline for the first time Kent Beck showed it to me I never thought that someone would show me a new way to write software it didn't didn't occur to me that there could be a different mechanism for writing software and I was completely floored when I saw this like i sat with Kent Beck for a day and wrote code with him and using this style and I came away from that experience thinking well till the last 30 years I've been doing something that didn't work all that well I'm going to try something different and I just determined I was going to do and I'm very glad I did because it's made things so much simpler so it's so much easier to get good software written as software written quickly that's kind of the issue right you make a decision working I'm not going to make the problem worse anymore I'm going to make the situation better I'm going to do that by writing tests I know that's going to be challenged by people who are worried about schedule but I am convinced this is the only way I can go fast there's a little bit inside your head and this little bit it's a binary bit and it if it's a zero you believe that writing test will make you go slower and if it's a one you believe that writing tests will make you go faster if you flip that bit to a one no one can stop you from writing towns if that bit is a 0 you aren't going to run test period it so you have to look that bit you will go faster if you follow the discipline I do you should try and flip that bit if you can anybody else um what do you think about using TDD without wallet they're here not enough a project our team that uses a trial um would you still be able to incorporate TDD here daily routine sure to test your development possibly did you do it and you do it for yourself it doesn't matter if you're in an agile team or not it doesn't matter a project a bad job now what does matter is if other people on the team are not doing test-driven development and then they start messing with the code you rub and they all write tests and they stay screwed by that writing test if that happens too many times you're going to wind up having a divorce there's no there's no way you can survive in a team where half the people are doing tests and half or not so you'll wind up splitting the team in half or quitting or something like that once it has become a personal discipline you're going to do it and you're just going to keep doing it and then everybody who who doesn't do it you have to keep away from your code those people who are doing it you let them in they can they can touch your code all in white because they're going to be writing tests right it's not your code it's the team's code the whole team can play with the code and improve it but the guy who doesn't write tests he can't be on that team you do you think that's the reason why maybe TDD isn't as prevalent it should be because there's a lot of lazy code and a lot of people don't do TDD and now reasons like that that's part of the reason it's hard because most people are is like at the environment so that makes it very difficult it's hard because most people are in teams where there are folks that are not writing test test-driven development is not not as prevalent as it should be but it is much more prevalent than it has been if I had a group of people five years ago how many of them were doing questions and development I would have seen maybe two or three percent nowadays I see close to twenty percent the the numbers are increasing dramatically and the reason the numbers are increasing dramatically is that now nowadays there are whole companies that are doing test-driven development keep all the programmers who adopted the discipline left wherever they were and they move to companies where it's being done so there's this massive reshuffling of people the test-driven developers are going to the companies where it's done and that's causing this division there are companies who do it in companies who don't and that will probably continue eventually will wind up with a bunch of companies that do and a bunch of companies that don't and the companies that don't will fail and die and and then everybody will do it not a quick question have you ever heard if you ever had a boss or a manager at maybe when you're first getting started in test-driven development and trying to get this concept across to them or to explain to them that it will make things better in the long run even if there's a more upfront cost I've ever had to deal with that and if so how to deal with them so um what business is it of the bosses whether you write tests earn your the programmer you're the one who knows what business is it of your boss and that's the first question didn't to deal with here yeah yeah of course I've seen bosses do this I've seen managers come in and say what are you guys doing why you're writing tests we're too busy just forget all the tests none of the managers business manager doesn't tell you when to write if statements doesn't say when to write while loops doesn't tell you where to put your semicolons or if he does he or she is just the wrong kind of manager in general this is a personal decision that you make it's a professional discipline you decide to adopt it and and you don't ask for permission to do that and you don't tell your boss you're doing it oh by the way I'm going to be writing tests from now on you don't say things like that you just do it I presume you don't ask your boss if you can wash your hands after going to the bathroom and you probably don't want to ask your boss if you can write that same kind of personal issue never forget why you were hired you may think you are hired because you know how to code that is incorrect you are hired because you know how to build software systems and the responsibility of someone who knows is the responsibility to say no when know is the answer you were hired for your ability to say no when know is the right answer what happened to healthcare.gov October 3rd October 1st 2013 they were supposed to turn it up they did turn it on why'd they turn it on it was a disaster disaster nearly derailed a law that was passed by Congress and signed into law by the President of the United States and a software failure nearly derailed it why did they turn a gun you think there was some programmer in there somewhere who said you know you probably shouldn't turn this on you think there were maybe a lot of them who knew that where were they why didn't they speak up actually they did quite a few of them spoke up the word trainwreck was bandied about quite a bit by the technical staff and yet they turned it on how does it happen you were hired you were hired for your ability to say no your success will depend to larger spin on how well you are able to enforce no when no is the right answer and you I think it was either wrote on a blog about the Challenger known as a book it was your book the Challenger the master yeah how the engineers fought and fought and fought and went through all the proper channels and then still they were told no we're going to launch and it costs the lives of those astronauts you know what what are you doing situations where you've gone through the proper channels and you know bike and healthcare.gov and still they say well we're just going to do it what do you design d2c deeply is an approach this is a deeply ethical issue because you are you're finally at the position where you're going to be a whistleblower you're going to lose your job you're going to have a lousy reputation and it's the right thing to do those engineers at Morton Thiokol who knew the risks of of watching the Challenger we knew those o-rings couldn't stand the temperature who wrote memos with big red flags on them saying you can't launch this thing who walked out of the room when the launch was televised because they didn't want to watch it blow up those engineers didn't do one thing they didn't call Dan ribbon right and if a Morton Thiokol engineer had called dan Rather and said this thing can't launch it's going to blow up that guy would lost his job he would have been completely discredited and there would be five living astronauts today I had hate to be those guys I'd hate to be those fire call engineers I'd wake up in cold sweats every night thinking why the hell didn't I call dan Rather there you go big ethical problem welcome to the world of being a professional and with that I think I shall bid you all adieu thank you for inviting me into your conference room this has been a lot of fun and thank you I hope I can see you all in the resources on pesto and development that you could maybe share with the group if anyone's interested in any further reading or lots of reading there's a ton of books on the topic there's a lot of articles too so there's there's two books whose title begins with test-driven development one of them was written by Kent Beck it's excellent the other one was written by Davis cells it is also excellent I've done an awful lot of articles on the topic there's lots of other blogs and things like that if you follow JB rains burger he does a long blog on all kinds of I'm a serial blog on all kinds of of test-driven development issues there's another one by James Shore he's done hundreds of blog episodes on test-driven development the the resources out there are enormous and then of course I'll show you my I'll plug my website if I can get this here if I can figure out how to do this okay I should be able to share my screen and take you to clean coders dot-com where there are tons and tons of videos and many of them involve test-driven development there's a whole series here on advanced test-driven development which talks all about all kinds of different stuff that you can learn about destron development mocking and the test process and test patterns how to write clean tests and all this stuff and there's plenty of other stuff on these videos as well so um that's my plug uh you you per turn the purl side and all I do not leave these videos are sold on my website any one company other well thank you again it was last a veneer yes definitely should would love to have you again sometime in the future if you guys don't permit should jittery love to say it again thank you but

Channel: CU.NET

Views: 12,252

Rating: 4.9565215 out of 5

Keywords: Test-driven Development, Java (Programming Language)

Id: qmS4ojQ1Pa8

Length: 75min 6sec (4506 seconds)

Published: Fri May 29 2015