 Welcome to ThoughtWorks. This is the new edition of ThoughtWorks Talks Tech. I'm Kareem Ahaman. I'm a QA and I have... My name is Angelique. I'm a developer at ThoughtWorks for two and a half years. Okay, so before we go into the actual session, I would like to ask you all a question. Since we are all in the software industry, what do you think is the top three answers that developers give when you find a bug in their code? Yeah, that's one. Can we get another one? Something really, really famous. You could even give that one. Sorry? Yeah, that's another one. That's two. But another one that really comes to the top of my mind is, have you tried restarting? Yes, so we want to prevent all of those happening. So we face these issues. We really know we've been working with a lot of developers, QAs, VAs for so long. And we all face issues. We just want to get better. It's not that we are perfect, but we want to see how we can do that. And one approach or the best approach to do that is to shift quality to the left. So testing. Everyone here knows what testing means. It just doesn't mean that the developer does something and then passes it over. And then hey, that's yours. You've got to do what you do. But no, testing actually means we verify functionality of the application. We catch bugs and also not just catch bugs, but prevent them from coming back. And also we sometimes use the test cases as documentation. So we look at the test cases that are covered and then we kind of relate that to the documentation. That's just a few reasons. But what about, you know, we get this a lot from the managers. How do we make sure we have full test coverage? How many of you guys have this question being asked? You know, we get that a lot. Can we be confident of all test cases are covered? And how can we prevent bugs from happening? So these are a lot of questions that we face and we'll see how we can deal with this. TDD. I am quite sure that everyone has heard the word TDD. What does it really mean? Test driven development. That's not something new. Everyone has heard it. But really, what is it? Can someone tell me what TDD is? Does anyone really follow TDD? Yes? Basically it is like understanding the requirement in the test cases before we develop any code. So it should have the predictability and the certainty of my function that will work before in hand. It should return 1 plus 1, 2. So this is my test. Yes, yes, we are quite there. So yes, like you mentioned, so you write test before code. Write the minimum amount of code necessary to make the test pass. So we don't write all the tests. We just write just that teeny bit so that we get the test written first and then write the code so that it passes. My understanding is it is the continuous process. Yes. Correct. So it's a continuous increment of writing tests and then you enhance your development and go on and on. So that's the next point. Rinse and repeat. Test first. If you really share this idea to someone who's never practiced TDD before, they would ask, why would you test first? How would you know what you're going to test? And then we will come back to the previous questions that we asked. You remember code coverage or test coverage and scenarios covered and bug prevention. So these are the things that we want to accomplish by TDD. So if you write test code, if you write test before you write your code, you ensure that all your codes are covered by tests because it gives you one, it gives you high test coverage. And also because you write your test before you write your code, you definitely can ensure all your code is covered. So we've accomplished that. How about the scenarios covered? The test cases that you get from the requirements, they will reflect exactly what the code does because you write your code, I mean you write your test, then you write your code. So it reflects exactly that. So you have a visibility of list of functions that you're developing. And then it also makes it very easy to see which cases are missing. We'll say you have a story and then you have TDD acceptance criteria and then if you start writing your test first and then your code, you could easily see which cases are missing to complete your acceptance criteria. So we got that covered too. And what about bug prevention? So when we think about tests first, we actually start thinking of the test more than the code that we are going to write. So we have a mental shift of thinking about how are we going to test this feature before we actually start even building it. So it's like a mental shift because in most organizations or most of our work that we've seen all these years, we see that we develop a lot of things. And then we come to a point and then suddenly we get these KPIs and stuff like that say, hey, where is your test coverage? We need to reach 90% or you can't go live and things like that. But eventually we go live with a lot of bugs. So yes, when you do this, you encourage edge case testing. And when you encourage edge case testing, that also helps prevent bugs in edge cases because you cover your scenarios, which helps you to invest more time in your exploratory tests. So we got all of these covered. It's easier said than done. So we will see in the next few slides and the demo how we are going to do that. And those are not the only points that TDD gives you. It gives you ease in debugging. Let's hear from a developer what ease in debugging means. Okay, well, assuming I developed a feature and I have tests that cover every possible scenario of this feature. So if inadvertently the feature changes, maybe another developer touched it, immediately the test would fail. And if I gave a readable name for each test, I would know exactly what went wrong. And that will also help you, I mean, will give you more confidence in refactoring, right? Yes. Because you have that safety net of the test that you've written. So when you touch any code that has this test coverage, even when you refactor, you know that if you do something wrong, if there's some issue with your delta, you definitely have that safety net of the test failure. Has anyone here heard about the test pyramid? ThoughtWorks talks a lot about test pyramid. Yes, I saw a show of fans. It's about how to arrange tests. So at the ground at the base level is your unit test. Then in the middle level, you get your integration test. And the top of the pyramid is the minimal functional or end-to-end test which are required to check from a user's point of view. And could you tell us why that approach helps you? I mean, there's many, many reasons, but could you tell us one? If you're thinking of automating your functional test, you cannot think of adding all of the scenarios and covering each possible combinations which may arise. So those things can be easily covered at unit or integration level rather than doing it at functional level. Yes. Yes. But if you start writing it exhaustively, what happens? It becomes really slow when running it. So in software development and delivery, we all know that slow means more money. Because the cost taken for the time to run the test, your pipelines become really slow, then it eventually means that the time to take a build from your code commit to where you want to deploy to production or wherever takes more time because I have been in one of the projects that take more than 36 hours to run their functional test suite. And it doesn't stop there. And to analyze failures, another 9 to 10 hours. So that is just to make sure that your test pass. But when you come right down below, if you have those minimal units being tested, which will add up to a lot more, it can run even in your developer machine. So even at your... Yes. So what you're saying is that meaningful piece of code, you can have thousands and thousands of tests. I believe not. It's a lot of work. We will get to that point. Where? I mean, yes, it's a valid question. 36 hours on a fast machine is a lot of things happening. Let's get to that point as to why it's easier testing further down the chain. So this is like the first session that we are actually going to talk about TD, which lies mainly on your unit level. We will have follow-up sessions that we will touch the other layers and we'll see how we can demo that too. Okay, now we get to the point of how can I do test-driven developer. Has anyone heard of the red-green refactor cycle? So red-green refactor cycle means you first write the test. You have zero code. I think we are starting from scratch. Then when you execute it, since there is no code that it runs against, it will fail. Then you write your piece of minimalistic code to make it pass. And then you refact it when it gets to a point. And this cycle goes in. And then after that, you come to the next test, so on, so forth. So this is called the red-green refactor cycle. In our demo, we will touch base on how it's actually done. Okay, so Riju and Jerry will pass you some notes, I mean, a piece of paper. I would like you to bunch up in fours or fives so that you could write down this exercise. It's a very small exercise. What we are going to do here now is that this is the functionality that you have to develop. So you are given strings of different lengths. That means anyone can input different strings. If the number of vowels are more than 30%, number of vowels are more than 30% of the string length, then insert mommy for each continuous set of vowels. That means if the user inputs his, then the expected condition would be h, mommy, s, because this vowel is more than 30% and it's continuous, meaning it can be just on its own as well. So this becomes h, mommy, s. Here becomes h, mommy, r, not h, mommy, mommy, r, because for each continuous set of vowels. So we would like you all to write different test scenarios that you can think of that you would try to, when you try to accomplish this functionality. So yes, I'll give you five minutes. You can bunch up in maybe a group of four or five just people around you. It's three hours. No, I've got it 30. It's three hours. It's two hours. It's three hours. Can you find out what it is? Oh, thank you. Can we go out and, can we go out and check on the progressors? We'll just get them. Okay. You know what I'm saying? Okay. We can have FAQ. I think the gentleman has FAQ questions. Okay. I don't see him. Okay. No, so he said, can the user go on giving cat dog? Then I said, the sample set is the same because cat is also one. So we've got another two minutes more. If that's okay. Or if you want more time. Everyone seems to be okay. So two minutes. Yeah. I was trying with the vowels I guess. It's confusing my mind. I feel curious to see how the people over there. No. So they have kind of like a between. Oh, wow. Wow. Wow. Wow. Wow. Wow. Wow. Wow. Wow. Wow. Wow. Okay. One more minute. Okay. Okay, so are we all comfortable with test cases we have at hand yeah, okay cool. So yes, there is a whole bunch of test cases that you can come up with for example empty string get an empty string because there is no vowels if you just input a string with no vowels at all you just get it written the same right then if it's just single vowel it's still more than 30% you'll get manual spaces and so on so on so on and if you have a continuous set of power more than 30% and another one after that I mean this is not an exhaustive list then you can have a special character see if the thing goes out etc etc yeah so it can go on where we see a logical point of we call it the scope of the story yeah okay so these are the test cases we have now agree with when we get the requirements about certain things about how we are going to test this and then after that we hand this over to Angeline who's going to start hitting her keyboard and do some magic to see how we are going to start building so Angeline how are you going to actually start with this well first I will pick the simplest scenario to work on because that's the easiest code to write and I would start by writing the test first for the first scenario of passing in an empty string and expecting that the output is an empty string as well so that means just that yes and it's only the test is it so no code yes the test first and then the code later after the test is completed let's see how it's done okay that's how it's done okay so I see that you input an empty string and then you assert against the same thing so this is just to match the first test case yes let's see no it's so yeah so we if we track back to our test I mean our slides before we mentioned about the red green the fact rings I go where we only write the test so if you actually see why this pair it's because there's no code that exists it's just a test yeah so Angeline what are you going to write next are you going to write the entire solution to match all the test cases no I'll just write enough code to make this test pass okay and our check feels so this is also at this point you just written enough code but not enough to pass the test so earlier I had an error the error is that the string class or the file doesn't exist so even though it's failing but it's not really failing for the reason that I expect so to make it fail for the correct reason I create empty function to return undefined and now it fails for the correct reason where it pass in an empty string but it gets doesn't get an empty string in return it gets undefined so let's see the solution this is the solution so right now it's very very minimalistic like one gentleman over there said you write very minimal blocks of code just to let that test pass and it's going to be a rinse and repeat rinse and repeat where we then develop something really big okay but not complex something understandable that will accomplish the functionality but not very readable okay let's see what engine has in store next so after getting the first test to pass I will look at the next scenario and I will look at the next simplest scenario which is passing in a string with no vowels so for the second one if I pass in SDR as a string I expect that the mummifier transform function will not transform it because it does not contain any vowels so I would write another test case with a descriptive name to say what is this test testing and I will pass in string and expect string to be returned with no transformation and at this point I expect the test to fail so you could see that Angeline has two tests over there one which passes and one which fails so in her incremental step she's written some tests one test for the next condition but she still knows that the first one passes because yes she's not touching code but that's how you start incrementally developing this we see what Angeline does next so to make both the first and the second test pass I would make some modification to the code just to satisfy the two scenario so these are very baby steps which we will I mean we'll show you the end result but these are very baby steps that you take to really get to that end goal and the reason we do these baby steps even though we are very certain that this is not the solution it's because we want to incrementally build the product so let's yeah okay so now both are passing so now her code predicate us to both of these tests so yes is it just for the demonstration that you're creating a bunch of branches or in reality would you also create a bunch of branches no I mean your first statement was the answer so just for the demo yes so that it's if not if Angeline keeps right yeah so in reality we remain on the same branch and type it out our self yeah just checking thank you so we'll just slide through to back to the slide to see what the next case is so we address still we've not addressed any of the tests with the functions so I think Angelina you're going to head next to the walls yes so next just to quicken the pace of this demo let's just jump to the next two scenarios which is a single vowel and vowel that are more than 30% of the string so assume we went through the same rate green refactor steps I would first add a test to pass in a and then I'll expect mommy and I would modify the code over here to make sure that the code here passes this so actually right now we've just been doing it and we still not seen any refactor in place okay what are we going to do next time okay so we have a class function then there's transformation of given input but we have some okay so Karim I believe you're referring to line for over here and over here so if we follow clean code principles we should give value such as a IOU a meaningful name so that other developers who are reading this code can easily understand what we have done here QA's as well so I did a refactoring where I extracted out a IOU into a constant variable and I call it vowels so that someone else who's reading knows that okay so a IOU stands for vowels and I've also extracted the string mommy and put it in a constant variable called replacement so someone else reading might know okay so this is a replacement word so we if you refer back to the slides where we said that Angie is very confident of refactoring because she has sufficient test so she knows that if she has a delta here and she does a refactoring there and tests are the safety net to catch them so there you go so that yes So just back I wanted to be in ankle box with you for 2013 I remember why I do is in the right production code to fix some cleaning test I mean I can't remember the details but so please correct me so just know there's no the test is okay to production code looks okay but there's still a refactoring that doesn't really fail the team so just to add to your point I mean clarify your question so you're saying that you have production code that does not have enough yes so that's okay so this is we are starting we'll say you're starting a feature from scratch then you don't have any production code at all right so yeah yeah yeah so if you start with something that you already have that's working that's fine that's not failing pumping in code is actually extra work so like you said when you when you touch already refactoring you write test for that so that if you actually look at this it's like you're starting the process from beginning that's why you write that test I mean I mean no we would but what I'm trying to say is if you have for example if you have legacy code right now would you start writing tests from 0 to 100 to finish to accomplish all that legacy code which is already working but if you are going to refactor that legacy code for some new new work for new enhancement then like the gentleman over there who said then you write test for that which gives you safety so the other scenario might be that we are in this great world where there are is some piece of code that exists that has been developed as TTV given that it's already now in production do we try to refactor the code without the tests like is there a need to refactor that code for making it better or whatever right with all the good one in the heart when we are trying to add some new feature we figure out that all this can be done better right but this for this piece there is a set of tests that exists because it was created in TV so in that case should be refactor or not because yes you could you could refactor so what we are saying is that there has to be test harness existing for that not harness I should say but the test bed existing for that before you go ahead try to refactor something yes I think a refracting is a little bit different from this TV cycle sometimes we just reflect for example into a fixed constant or anything which doesn't really change anything to interface yes yes to my point is everything should be when of course making it's cleaner to be understand by many technical users and the point is if you really follow the TV and stuff I think we only face the product I mean my C product code doesn't necessarily to be in product and which is distinguished from the test code product code actually you know they only will toss the product code to fix a red one which means we do that but when we do the refactor we potentially work something I'm doing that it is still still very yeah okay so I think our demo is more during the development process yeah in real life projects normally if a code is working we will not touch it unless we need to add something new and it is in that place yeah sorry yeah is this just that you're using or would you use just in a real world environment I mean there are different choices you could make any thoughts on why you're using just in this project okay well for Java for projects yes I would definitely use Jess and even in react projects which I will also use Jess because it comes together with the framework any other questions so okay so I understand for the demo purpose is start to take this approach yes they will start with baby steps over a period of time the babies grow bigger and they become more confident are there any guidelines as to how big a step should be because if it gets bigger then this thing uses its value so yes I mean that's an entirely different topic you could there are a couple of books that we will recommend at the end of this thing but I don't want to go too much into detail because then we will go in a different direction but yes we will recommend a few books that you can pick up and read about how to maintain clean code how you could do refactoring better but my question was more about like because these are very small steps yes right if I'm a developer and if I look at it and I'm like it's like it's too small and I'm trying to have to like you know switch between the tool way too often right so are there any guidelines for me to say that even if I'm like a pro developer I shouldn't be doing a lot of coding a lot of just writing tests rather than like you know just testing and coding that's the kind of balance that I'm okay so we we actually want to touch base on a point called Yagney but okay okay so normally beginner developers who first joint outworks and have to do TDD for all their projects the feeling is the same means I have the same feeling as what you mentioned like I can do this much faster than that I'm wasting time okay however after some time a couple of months of doing this I start to see the value in that is that it taking the baby steps will make me build the product incrementally and it will not have code that's redundant in the solution means every piece of code is related to a test that I had written first and if I spend time to write the test it means the customer wants this requirement so it will be impossible for me to write a transform function that have some extra code that doesn't have a test so after I realized that and that it gave me the safety in refactoring I accepted that that I follow it yes yeah I've also seen people use single responsibility there are many rules like this so yes shall we move to the next one sorry is there any other questions very very fair point I mean I've heard that a lot of times so the thing is a lot of people say that agile you need to deliver really fast right but agile doesn't happen overnight to get so the thing is you might be able to really will say you do agile and you have iterations and then you develop and deliver something in your first spring or iteration or what you prefer to call it but over time when you don't actually invest on enough on test you'll have really big code with very minimal test and then after you get to maybe iteration five six you're like you know scratching your head you can't refactor you can't do anything then starts your deep so it's not yes for your first few iterations you will be able to zoom and you know deliver really fast but when you start to date then the management brings up saying hey where's your test coverage why didn't you think about it so exactly so what you need to I mean what really the management needs to understand that if you really develop in TV with TV it is just one practice but there are many things that needs to needs to bundle up and go like you have to have proper CI you have to do proper reviews you have to do proper ceremonies so when you have those in place your first few I mean your velocity at the beginning might be slow because you don't have the confidence to refactor you're not sure how much functionality is to add because it might break something else but over time it's going to get you to a very stable state where you are going to give your management or your customers steady deliverables almost every iteration so that buying it's not easy to get but once you get into that phase then they'll start to understand ROI I have a comment yeah I think if a manager told me that my reply would be would you want to pay the cost now upfront cost of developers spending time to write tests or do you want to pay the cost later when the code goes to production and there's a lot of bugs and the customers are unhappy and still it comes back at the job like you cannot go to production because your coverage is 80% not below 80% the same so what the developer generally have the hacks like I will just call them it will at least cover the coverage and which is not actually the test coverage and what we are talking about is the scenario so how exactly to measure the actual coverage because we cannot go each and every line and take the coverage back because so now I know that that would be actually you can do that with a cover still you can pass the 90% I mean I would really state that as a problem in between people and software like it's not really a software problem it's not really a people problem somewhere in between because this code coverage I mean stating that you have to be this ultimately transform somewhere into KPI so yes so your your team needs to be aligned with this your team your managers everyone needs to be aligned to really understand what by doing it gives you some people would say 80% but we we are not really forcing on the mark we need to make sure that we are confident to give you confident for the developers for the QAs for the team to deliver so I really don't know to say whether is 80% correct is 85% correct or it's 50% correct so that's a very broad discussion that you your team your managers need to agree on how you want to work which is not in your scenario so it's good of the subject to let you know I'm just writing the scenario what I can think of it and what will be the requirement means how we can justify the requirement in the scenario the number of scenario we supposed to write and actually make the code as the actual so we usually practice something called yeah we do pay also but when we actually pick up some work to be done on some development we have something called kickoff where we have like a feedback session about what we want to achieve like can you maybe show the slide sure so actually yes even I can write like loads and loads more but what we need to get is the correct sample set for an edge case what the happy part would be and so on so forth we agree on so if you get proper sample sets about what you want to test and you make your code adhere to all I mean if it's one if you pick up one piece in the sample it should adhere to all the entire samples so it doesn't mean that you write maybe 30 scenarios and then you know you back your keyboard and write a lot of code and test that doesn't really make sense what so yes you're right so we need to pick up proper sample sets and agree on what we want as the acceptance criteria so what what is the what is their good cuffs such it becomes a subject to write in yes I may feel like you know this is the shit for this this might be the valid scenario something like that so there should be some standard process in the standard agreement before the actually start of my day-to-day itself isn't it so yeah I mean yes so the question here is what am I testing yeah right what am I testing yeah now I will decide based on the rules that were in the problems like 30% and engine can you go and continuous right continuous 30% these are some of the rules that are available the problem right and based on this I will have test scenarios the test data basically I will see which are overlapping so let's say if you go to the next slide so if you see BLA right that's a test data right you will not test GLA that's a duplicate based on this you will be able to filter out what exactly am I testing so even beyond this let's say there's an integration test right so the integration test what exactly is testing is it overlapping with a unit test can that be covered in the unit test which function and which piece of thing is being tested so that will help define correct scenarios so yeah like what did you say it's like BLA and GLA will fall into the same sample set and you pick up one and then go so we need to agree on what exactly needs to be I could you say what exactly needs to be tested really when people pair right that is the type of discussion that happens to people so I just want to share like you know I have seen some places wherein actually if anything requirement get changed basically B first determine the test report and then we identify what was the requirement basically is it something wrong yeah so that's our documentation right yeah we actually do this when customers ask us to give us the documentation we point them to the test because we do TDD in all the projects so test becomes the documentation and they are lying document they won't go straight so that's very valuable okay can I have a moment okay so we were here where we refactored the code extracting out the vowels and the replacement to make it more readable and the test are still passing okay so the test act as a safety net to ensure that any refactoring we do to change the structure to make it more readable does not break the core functionality of this transform function so now we see we've written a lot of tests and yes to cover a lot of scenarios we might go ahead and write more tests actually do you think this is actually very very tricky you mean the code I've just refactored it so yes the tests okay so for the test wise I find that the test names are quite readable however like for example on line five six ten eleven I see some duplication there for example on line five I first initialize a new instance of string and then I call the transform method and this happens in every test so I don't think duplication is clean so let's see how we could refactor our tests as well okay so assuming we went on to do more tests for other scenarios okay and to address Karim's question you can remove duplication by extracting the common lines into its own function and then calling that function so in actual fact what you're doing is you're taking all the repeated code and putting it in one place and then you just call it at all the tests just to add on to here so add on to what Angeline said so when you have a lot of tests to actually verify functionality actually these are very simple scenarios just to get the basics also ordered when you write usually your test can become a little bit complex but when you refactor that also and keep like you'll say a QA comes to talk to you and say hey what's with the story how what kind of test do you have in place when you have it in a very when you have it in a very read down okay when you have it in a very readable format it's very easy to identify what your specs are or what kind of conditions that you test so then the QA has more time to invest on exploratory testing like for example we don't in this we don't cover like special characters what if we input a special character what if we try to do something very unusual what will the system give so he can then think of you know really trying to think out of the box and break the system which will help us to what we discussed before about preventing bugs so you have your acceptance criteria matched here and then you give the QA more time to invest on exploratory testing but we'll say you don't have this now what the QA has to do is he has to go and really verify does this happen if it's just think of it as a very complex situation then it becomes very cumbersome he has to go write test cases blah blah blah check all of this but when he sees this when he sees the test passes then obviously yes he has some confidence but obviously the developer also has to be a little bit helpful not like passing exit zero condition at the end of the test reason yeah barring that then you have that confidence Karim are you speaking from experience or okay so when you have the test cases okay and you'll read back to the test cases yes how do you know that you haven't met something else in your test cases okay so when we do refactoring we try and focus it on one side at a time so earlier I refactored the code the string modifier code and the test as a harness and a safety for me but when I refactored the test I don't touch the code side so now it's like the other way around so the code is helping me verify the test now actually then yeah like I really said your only delta is just yeah so at this stage it's the only responsibility of the developer to write all these basic test cases is that what you're saying yes and when you write all these test cases do you also have an agreement with your stakeholders that you share with them that this is the basic criteria that will be starting the development yeah yes sometimes as we write the test cases and we think about scenarios that the customer did not tell us we have to go and clarify before we can complete this feature okay so yes we can go so on so forth I think actually we can show what like the end state end state okay not that much yeah you can see that we've covered all the scenarios we've covered the scenarios where we have consonants and vowels together and we have the test all to identify don't worry you don't need to take photos we'll share the code repo so you can play around with it you can try it out yourself and yes that's the demo any questions on the demo you can understand this is the demo stage let's say we change the context let's say this is a job interview if you are playing my role I offer you this question I ask you to write the code but you're still following the exactly same and that's not as well you follow exactly same okay obviously I would suspect you must start from this one what is your start with the typical your perspective so my answer what's going on with the actual TV so my response to that question would be it depends on which company you're applying for obviously if a company that you're applying for does not care about tests then you jump in but if it's a company that it's yeah then definitely you should write the test otherwise it will be failed the interview but do you still start with this training of this stuff and then 20 minutes after you really get into the point you probably won't get the solution for us right okay so if time is a constraint in the interview then I might tell the interviewer that we have a few assumptions is I'll get to the meat of it and not cover the error scenarios yet so in that way like for example I will start with something like this and this yeah you should get higher okay so after few test cases obviously the old difference protocol with metrics could be 100% even these different conditions a lot of it fails I mean that's not big problem if a lot of it fails you still get 100% the question to me is how should we look let's say measure your test case obviously we can't test every single combination until a balance you feel yeah I think it's enough you feel enough all your program you guys feel yeah enough is there any let's say I don't know so any project do you have any other questions how to measure this when do you say yeah I think I got some last test cases I mean obviously this is not a feature probably some functions are not exposed to any user only you as a developer you know you are creating some public method and only you know what this method is going to serve and then you know the test case when do you say yeah enough test case well normally when I'm sent to a project that project if it's an existing one it will have a coverage a threshold so if you don't reach a threshold you cannot push the feature and of course the more critical the software the higher the threshold like for example if you're working for a bank definitely you want a very high coverage yes yeah no comments on that you mean for legacy code yeah so for legacy code if we wish to refactor and touch it the only way is you have to read through the whole mess and write the test to make sure that anything you touch did not break whatever features that the code is supposed to do yes yeah definitely branch to another branch and refactor on the other branch yeah so it doesn't affect the current thing yeah so for legacy code can't do tdd cause the code is already there so you have to do the test after since the code is already there but for any new features that go in they can do tdd thank you I think everybody knows you can get a little bit of writing JavaScript and hang it out fast you know with your you know testing you talk about your new hires spend 2 months doing their so can you get really good at it you can bang this thing out half an hour or 20 minutes so does it still take you half a day or do you need to make a difference does it actually take to create it's in the real world well truthfully the other day I was with friends and we were doing code challenge together and instinctively I created the test and then they were like wow you're writing the test it's slow but in the end I finished before them so after that I was convinced that this is the way to go so I guess after some time we can no longer write code without the test it becomes like second nature yeah ok it's smooth so yes you could download the example here anyone knows take we'll also share the link to the repo on the meetup so if in case you miss it out you can still have a look so this is as I said before what kind of what kind is not the one I mean that's good but this is a much better we do discussion every now and then and it's very oriented to curious but everyone is open to join so so we have a meetup page we regularly post different meetups we talk about security sometimes the in-price code how we test it and also general keyway stuff so if you are happy you could join so it's just at www.dio-me-dup.com and you search for this group name sorry I can take a photo ok so yes some of the books that might answer your question you could look at some of the books that I have read also there is also I think it's Ken Peck who wrote test-driven development so also you could read some things like things like thank you