SwanseaCon 2015: Christos Matskas – Common mistakes in TDD, can you guess?

thanks everyone for coming it’s a beautiful day out there so let’s all just viewing here I knew I had silenced my hands when I saw the schedule for this session no because I’m going against some amazing speakers on the other room but mainly because I know it’s just after Lance so I want you to fall asleep while I’m talking I’ll try to keep you all away that’s my goal so let’s get started my name is a case of masochism I work as a software consultant I worked in a lot of different projects maybe around about that stack and I’m working things and just one presently doing mobile apps all the way down into much larger projects with tens of developers and a lot of teams spread across the globe different times and different cultures once a potential developers about make eleven developers developers so today I will be talking about test driven development and the things that can go wrong or the mistakes of developers do when they use DVD in the development proach then I will expand a little bit and like a reference about the larger issues that we deal with TD when it comes to development and I will close off with some suggestions about how we can use TDD to make it better for our development process and how we can use tdv to make it better for us I would start with a brief explanation about what TV is another you they have already been a few sessions today or yesterday that working about TDD i’ll try not to spend too much time on that but for those of us that long practice of the haven’t heard about TV for those developers and i’ve been living under up or have been developing the basement for the last 30 years and had any human contact tdd is a developer approach that combines test driven or test first Lisa continues refactoring across by test first self-explanatory you write your tests first before you write any production code and now that’s the way that you use your tests to drive your implementation and by the continuous refactoring I mean the idea of using the reads Red Queen refactoring cycle when you start with your test first and we write a bit of code then you write a bit of more tests and you are local until you implement us tonight stuff just the right amount of code or what like you to come in the future you there’s another important thing that we to do is to clarify what TVD isn’t now some people tend to confuse TV deal with therapists and that’s not right because TVD is actually driving or is used to drive unit tests but are not the same you’re hearing this I used to fine with your code make sure that does exactly was supposed to do test-driven development is not you noticed this need to make value for a clarification TBD tests are also not you user acceptance tests I’ve seen this in the past where companies have a very comprehensive tests of DVD test a new test miss a right opportunity is quite a fancy to toggle everything I think where we got the production reticle let’s if it does not a case user acceptance tests are they’re developing behavior of your application ddd is there to help you with the design of your application now know what DVD is and what isn’t i would like to explain a little bit about what TV can do for us before we start buttering and saying what you can go how do you can go wrong so first things first we got small concise pieces of code the idea that you write minimal tests in the minimum code to satisfy your test then you expand your tests and then you expand your code based on that soon as you reach their optimal size which is the minimum amount of code that satisfies your requirements or your functionality we stop no more no less small pieces of gold small sucks it can help us sell short feedback loop that continues report on our unit test through automated tests or through our test fit allow us to have a clear idea of what can go wrong or what goes wrong as soon as you are the new feature or as soon as you want some code if it’s a bug then you’re doing this to let you know whether a hospital asad feedback loop means that you don’t have to wait for 30 lines of code in your fashion to see whether you fail or not once you study right here tests another benefit is that

it helps design specification allows you to force you enforce you to think about how great your unionists and that in effect forces you to think about how to design their code starting from this small and specific to the overall and larger then that’s how you do your design and that’s one of the great benefits of DVD this is time to do bug fixes and adds new features again this is related to the short feedback loop but there’s been a lot of research and we’ve tested real teams and we found out that teams adopt EDD as the development approach in most cases tend to be a lot faster when they have to close items those tickets or vice in the future so in this the time it takes to fix off and finally it it uses the time that you spend in your debugger your tests are there to give you immediate feedback on your stuff so by having a comprehensive suite of tests it means that as soon as the bag is introduced or as soon as something breaks your test can indicate where things go wrong by that you can identify the Disco that doesn’t work as expected going to fix a drop on you fire the debugger you find the line of code that these behaves let me fix it you don’t have to go through the full path of finding out the application going through the failed paths you figure out what it is it’s you spending a lot less time debugging and a lot more time writing the final eight makes your food a lot more adaptable TDD drive unit tests engine tests give us confidence by confidence we can start adding no more refactoring our application and we can be a lot more confident when it comes to respond to the ever-increasing needs of the business by that I mean it’s easier for you to implement me but a feature or fix a bike because your code is giving importance I’ll give you an example about that I was working in a project recently where we had the National application web forms and the web for Speights had not a single line of ASP it was all driven through JavaScript there were eighteen hundred lines of uncompelled and test exhausted not a single test and that exhausted would do multiple close to the backend get data from the API and use the data to drive the dome every single element that dawn had to go through a number of Ajax calls house absolutely appalling now imagine my fear when I was told I had to go another text books on that formatting a textbook cinematic go through all the JavaScript code figure out what had to be done and then drive walls up down to the database and all the back to share season all these airs without a single line of you who would feel confident about trusting the physical appreciate nobody will show DVD and getting tests do improve our confidence and that’s implied whole thing to have so we’ve seen what you a test sorry okay we’re saying what they did you can do for us but unfortunately i’ll get everything else in coding there is no one true path there is not one real solution to a problem and with so many things open to interpretation it’s quite easy to lose track of what’s happening or stop its they had to justify whether something that you’ve done that’s the right way or the wrong way so next i will be talking about things that can happen or things that developers do wrong when they approach TV or when they talk tickity in their developers one of the biggest things that i found is not using motive rebel you would expect people to you to be a debt and understand about the walking to do for them but they have been cases where we know that unit s need to run isolation we know that invests need to run a standalone pieces and things need to be abstracted through mocks and fakes and stops now the worst thing you can do is not use an established mocking framework some developers choose to enroll their own manual box with workshops in fact if you want to go down the route you just have to invent a motive therefore you eaten by a lot smarter people thank you as an example I work in a company where we had a large project San plus it was an exciting project created all new stuff but hence against common logic we decided to implement multi in a very convoluted way rather using a multi framework we decided to create our own test complementation of every single interface and you can imagine how this can go wrong when you

have 50 or 60 interface that have to be implemented both in production and in test code every change make the face it’ll be savings in two different places made it up with a lot of test code that was empty methods because we tested and it became a maintenance nightmare you would have been a lot easier for them to have implemented important framework and again spend a lot more time watching cat videos on the internet professionally so the next thing that tends to happen quite frequently is three months test setup from having no motive framework to overusing your materials it’s very easy mode frameworks make it very easy to over set of things and with objects in our code base to have multiple dependencies I’ve seen cold with nine ten dependencies all had to be locked out and knowing exactly how many methods and how many interfaces you have to walk out until your DVD test and run in full success it’s quite hard n square isn’t go over serving everything you should be able to describe your test your the assertions of your test methods without using n if your method sounds like tested you can get by ID and usernames blah and his eighties thing then you’re the Europe there are too many sessions there and that will make your code a bit harder to test it’s a lot more touches for your hearing test to fail and will make how to feed it meant a notice in an ideal world you want your test to have been one one more thing so one year test do one session now obviously now glass implodes I will make your code a bit more expanded but in effect you gain weight ability and Clyde you through your code so yes makes things a bit more how to implement and adds about go but obviously the gains that you get from the climbing are include canto babe now necessary testing obviously we there are so many areas in our code that we need to test it’s very hard to touch where where to write your tests and we’re not to write your tests I’ll give this example as a as a pointer now we already have student surveys that falls into a student repository service which is already been a mock tower has already been tested by another unit test now do we need to test the get by ID here we already know that I repository standard poster will return the right object so by testing this again with not only a duplication what you want time and effort to you write your tests and we’ll also add to your maintenance friend online once things change it’s very important to choose that I think’s to test a Triton so I’ve gone through the the big issues with the issues are the developer space when they do TV it’s a quite common and appreciation was already following the trouble but I think there’s a larger issue when it comes to these this species have been summarized here for you and there they are based on my experience and they’re talking to different things and this is some of you may agree or disagree with that so more open to discussion afterwards if you find something that so false confidence TVD is so young testing is all about confidence developers need to feel confident about their code and that confidence need to derive from a comprehensive set of unit tests and reasonable code coverage tdd should not be dictating whether we feel happy or sad of our code tdd should not be the true path to code confidence now there are some people that are PVD advocates say but obviously test can be bad right I mean we have everything willing to test here so why do I be rebutted obviously by forcing developers do you go down the TVD route sometimes you get a bit of a plus sometimes you have unnecessary friction because if you have the team leader or the company forcing down TVD the developers throat and then ddd and then the developers push back I said you know what tickety’s dead it does really work for me then develop fiction a dozen I need to be there you need to be able to feel confident about your tests because whether they use to

needy or not now it’s a sad case but you know Allah I’ve seen teams work TV was forced out to them and some of them were coming up saying look I’m happy to do TDD but feeling a bit bad because it does really work hundred percent sometimes I can do TDD fifty percent six percent sometimes I can do more but sometimes the less there the company has timberland features the spread is moving along there’s time and cost constraints so I can do a representative theme no it’s not good I did go back though and I do you fix money anything to us so is that it does something developers should feel guilty about does it really matter whether your confidence comes for all the tests that you’ve written prior or after the fight I think TVD is one way to feel confident about your code but a comprehensive set of tests and usable code coverage is what really really matters testing too much is expensive testing is from us having tests there it gives counters the team it makes everybody happy and it promotes good old practices this card activity for the first time can be a revelation it can be altering the door to a whole new world obsessed by the green won’t write test you want to test everything I don’t talk about your automated coverage tools like and cover and n crunch that they give you instant gratification and needs to feedback about how your goal ph and then you suddenly have developers are trying to overdo it try to cover every single thing under the Sun this is also quite prevalent with new developers an experienced developers that no guidance about what needs to be tested and whatnot and eventually you end up trying to test everything now obviously facing two months can be too much unfortunately in the real world testing costs it’s a noble goal to help it’s a nice thing to have unfortunately testing too much can hamper the performance of the team now every single line of code that you write has to be written as to be tested has to be read and understood by everyone the team to make sense so for your codes but just best quote to make sense it needs to give more back than it takes to write it if it takes more tragic test run text we get out of it and obviously it’s counterproductive and it can be costly quality test induced by convection cells now we’ve already mentioned that tickety can help us drive design the ddd mantra is that code should be easy to test first our young test need to be small concise and fast around and should be run in isolation by using the TDD approach of do as little as possible to get things done it means that we can actually talents architectural design by unnecessary interaction and conceptual already ddd is good and advocates want to boost it down unfortunately sometimes that case of all fiction the case a lot of problems and eventually your design suffers when going through the premise then you write your code in a way and needs to satisfy the yentas your architecture is going to suffer because it doesn’t focus on the bigger picture we focuses on the fact that is to satisfy the best criteria he has satisfied big happy your test framework such it will probably make sense to say we should sacrifice in the author of TVD and it’s continuous red clean cycle all the architecture design you start to drive everything forcing the real world this has some really terrible effects to the overall application performance we should always think about how to do architecture not based on the testing framework that we use for the test needs but the actual business needs and what applications should be doing for what it is heavy what I’ve already spoken about

multi we see that some things choose to do a lot of watching some developers to know to do any mortal whatsoever but this is a bigger idea now we already discussed about the fact that I can test me too in isolation we discussed about the fact that the testing to be fast and efficient and assets we need the application to be able or the infrastructure of our application to support this now if you are going to use a monkey framework then your application needs to have the right criteria to do so so certain what the framework why do they have interfaces implemented because I want to bak anything if a specific now you see or dependency detection in there and so on and so on in effect you might not blow to your application and you might make the architecture bit more complicated only in order to use TDD so it needs to be balanced out tickety in the real world that’s that’s one of that probably one of the most realistic or pragmatic things have come across we know that the activity is established we know that TV is out there everybody knows about DVD when you apply for a job where contract all of the thick boxes is you need to be able to do DVD now obviously most of the companies out there that the country distinguish between comedian hearing tests because everywhere happy in a request in PDP not a single developer was developing impunity whether all some of them didn’t have any witness let’s ignore now so give me their world in an ideal world you would join the project or a team that have already been working in activity practice or your might be joining in crystals project where you start from scratch and there’s nothing the color case and that’s where you can show apply the TDD ideas however when you join a team these days in most likelihood you’ll be joining a larger team as an established code base that has a lot of code out there and you’re called to help add more features or fix bugs or take it the next level now obviously you’re excited you say you know what I’m going to go all tddi on this thing and make it better so you’re assigned your first task you open up the code base and suddenly you are presenting with say things if it’s all DVD and what you find and oak in this regard at rangoon however most cases you’ll find a few tests that provide a bit of code coverage maybe twenty-five thirty percent which is quite nice but a lot of things are missing or you’ll find no interest which is the other nightmare however if we take the scenario of thirty-six percent a test ten percent code coverage achieving this out there you start realize that you want to go on your features in TDD vote one for some infrastructure doesn’t support it so what do you do there are two oceans there go either do your bit and you go and fix the stuff that you need to implement you fix the back you want the feature you got some game test by extending the existing FS or you want some you invest on the future you’re working on and you move along or you decide to start ripping things apart and start implementing and interfaces and trying to make the application to work that way to do TDD now in any code base as more than a few lot of thousands of code that’s going to become a nightmare you can end up with two different strings and you get seven people in the team working the TDD stream trying to move along and then you have the other people on the team trying to fix the relation of the existing code base eventually in most cases businesses and say don’t have money we don’t have the time scrub tdb make it work and this is the sad scenario I’ve worked in a lot of things and I work in a lot of projects are only being likely to use potd ones and it’s very hard to try to give your application to make it work in a pure TDD way only because of the constraints if you want to do cute EDD then you’re going it’ll stay unless you start rewriting the whole press then finally not everyone keep thinking that TVD terms think as I said I’m working lot of things I’ve worked with a lot of people and when I asked them why do you not do TDD we go it doesn’t work for me it’s not the same it’s it’s hard for me

to think those terms I’ve tried it down a little bit it’s not the way I solve the problems it’s fine for some people some people can go from the very specific and expand and that’s how the idea works beautifully in that scenario however in most cases you go from check out this picture that you have to implement break it down small pieces start implementing stuff right a few unit that’s around it then write a full year test fit around your feature and you’re done and to me I think that’s more like a 7030 split seven percent of the people like to think that way I don’t know if it’s because we’ve been cultivated like that or because we’ve grown through our processes and themes and development to work in that way and change the your mental thinking takes a lot of effort and a lot of time and in most cases teams companies and even the people themselves don’t want to see is a processor so yeah I think these beautiful TD works but it’s not forever so it’s paid this happen when you see the ends and things and company saying by preventing it in you’re going to do TTP otherwise you’re called small objects so how can we make TD board for us can we make you do work for us that’s us the other question do we have to be a purity glee one hundred percent or then we’ll just mix and months and make things work in a very way nothing weekend iimm provide personnel I like to use the right tool for the right job as I said most code basically enjoying you’ll find out there is no way for you to implement any deal without going through the health and maintenance and refactoring on the other hand it doesn’t make sense to try to apply to DD on everything doesn’t make sense to test everything let’s take at NBC for a model view controller you take up one’s there and I think only one of them can be truly tested or should be tested and that’s your model when it comes to the controller the controller is there to to take requests from the user pass along the application and then it’ll a response back to the Asian assets we know that controllers have a lot of dependencies and add a low of coupling in which case we have to use a mocking framework on top of everything else to walk out the hip of modules and dependencies for the controller it makes a lot more sense to test your controllers through integration tests because at that point you’re a cannoli ourselves working you’re not duplicating the gate by ID or get users by calling the same test method you’re eliminating your you’re testing there and you’re also testing your controllers to education which are better sitting on the other hand we have your view we seized of the top of the stack and Assad is more like a presentation layer rather than a functional layer to the application it makes no sense for us to unit that’s the up the you it makes a lot more sense for us to do user acceptance testing and UI testing and to end testing for reduced because this is where the true test lies with the vision is the presentation is what they usually sees is the behavior of the application right so I will try to have some suggestions here about how we can make DVD and how to make testing work better for us and then I’ll open the floor to questions that’s the example of twenty percent here there’s not one of us using the intestine that controller because we’re the testing services code to test ratio yes writing test for every single thing under the Sun can be good but we’ve already said that there’s a large cost time and investment added to the testing right the more tests here and more lighter Cody have the more maintenance you have to do in an ideal walk you want for every method you do implement give a test ratio of about two one method two tests to nicer sessions and gives you good confidence on your function anything more than one to two will probably add code smell who’s ineffective month thankful dead and problems later find the right coverage ratio don’t aim for 110% donate 411 aim for ninety five percent aim for 75 cent tweak the rules make them work for your team it’s like style people are voicing your style because it goes Mentalist as you are a into your solution you don’t have to go with the default settings find the right settings for you make it work if you don’t like your methods to be at the top when we left off at the bottom I bring the team and

make it work it’s the same for Europe cone cupboard dawn in 495 send aim for the stuff that makes sense don’t let your ph that your mind just push it down saying you know you only have so much covered goose back and say this it doesn’t make any sense this is why we’re doing this this is why we’re adding integration tests that’s why we’re adding here as much why we have you itís to make sense test to take less time to right now it takes so let’s take last night that right then it takes to write your code if your tests take longer to write and your code then you’re doing it wrong the test subjects upon your code they’re not there to write everything don’t try to drive everything through your tests see the clear separation between unit tests integrationists again I’m messing that it’s very important to know what you’re testing and why you’re testing it don’t test your controllers don’t test things are better suited for integration tests you not only application it causes time and effort in effect you’re gonna be the one maintaining all those tests and find the best approach to code first I don’t say don’t do TDD I don’t say just do TDD find the right approach to you for some people it might be a 2080 right twenty percent of your test first dry your solution and they’re not the eighty percent of your test so that at the end maybe you like a 60-40 split it doesn’t want to find things or find the rest of what makes you happy gain your satisfaction but from writing code because there’s a lot of people are trying to do TDD and really guilty about not writing all day all their tests first it’s a really guilty about so when you just for everybody else general gage asking whether he should be a setting is set up for his game test before it even starts ascending is actually a test it’s not great yeah so I think you need to find the right guy right bounce over there usually the set up and then teardown of your unit this are there to support the unit test and you should have confidence that that part of the coach work in expected way are you using for example system yeah well he trailer yeah is that a framework that was tested that I was created by something else actually you cake what so wait as the actual a file system framework or waiting yep I think she had confidence on on your framework or what you’ve written so that part of the functionalities already be tested by another test so when you use a functional teen another test you already know that was covered by something else at that point you’re duplicating your test because you’re testing that somewhere else on this are you testing us somewhere else but you’re not testing it again you don’t need testing anyone it’s pretty low little bit you know just make sure the intestine things like that’s like thank you very much people go and try to write him to squaring the framework well you say no but people try to do that and the advice is don’t try to test you your end ephemeral because it’s been tested by you for something by somebody else when you use a bunch of framework to support your tests don’t try to test out as well I said you don’t need to test everything under the Sun in this case just now you see if that’s the top part of the function or somewhere else and just focus on the staff are you my desk on that specific test class when I press attaché okay thank you very much for our attend my session and custom their own if you