The Ultimate Coding Workflow

so I've been on a journey for over 20 years how long have been doing this professionally and I've been on this journey looking for what's the most productive way to produce high-quality coat [Music] so first of all it's not about tools we tend to get obsessed with tools and finding the latest greatest tool and we think that somehow if we have the right tool if we just find the right tool the right combination of tools then that will solve all of our problems so tools are great and they can help but the point of what I'm going to show you is not that it's not the the tooling in fact even the the fact that I'm using javascript is just because I think it's a language that most people are familiar with it's sort of the the most common denominator amongst languages so that you know everybody can follow along but you can do this in almost any language almost any IDE so what defines a productive workflow are what's the key to being productive so if it's not tooling sort of what is it and the way to explain it is this so whenever you're coding a new feature there is always unforeseen complexity so you tend to get to a point where you kind of hit a wall so you understand basically what you're being asked to do you understand that the behavior that your application needs to needs to exhibit you understand what the what the client wants more or less there's gonna be some conversations and it might evolve but you generally get what that is and you have an idea or a sense of what its gonna take to do that and inevitably you sort of hit this this wall this unforeseen complexity or this unknown problem and it sort of you know takes your estimates throws them out the window and it really messes with your productivity the goal I think of a productive workflow is to solve for that unforeseen complexity and what I mean by that is you want to be able to get to that point where you discover this unforeseen complexity as soon as possible and so you want to start your work in an area that's going to uncover that unforeseen complexity and you want to work in a way that's going to get you to see that unforeseen complexity sooner rather than later and so that's the that's really the point of what I'm about to show you and there's some other things in here that might make you a little nervous or uncomfortable you might have some assumptions about but don't worry I will I'll go through it and I'll explain and I just asked for your patience hang with me and you'll see this is gonna I think it's gonna really help you because it's it's really helped me listen if you're new if this is the first time that you're watching me or this channel I invite you to subscribe to learn more about how to improve your code and advance your career subscribe hit the notification bell so that you don't miss an episode I'm pretty excited to jump in so here we go alright so this is basically how I set up my monitor whenever I'm coding so there are three distinct sections so on the left-hand side I have what's called a spec so this is the this is the specification for what I'm going to code on the right-hand side I have the code that is going to implement this specification and on the bottom I have a test runner that is watching for changes and giving me consistent feedback and now I know you're looking at this and you're going well hold on a minute this is you're talking about test-driven development now and maybe you've tried test-driven development and you're like oh man and I tried it it doubled tripled my workload it was so slow it didn't help me at all it was confusing I didn't know where to start look bear with me I will show you how to do what I consider to be test-driven development in a productive way I'm hesitant to say the right way I don't want to get into big arguments over what's right and what's wrong I think we do that too much in this industry but in a way that I have found at least for myself can make you very very very productive and I can avoid a lot of the common pitfalls and traps that I think a lot of people experience with test-driven development I think there's a lot of TDD out there that is sort of setting you up for if not failure at least for a lot of a lot of pain and I'm gonna try and show you in this video how to how to avoid that ok so notice a couple things so one I've written the spec and terms of - dues right and so you may not be using a language that or our testing framework that has this concept of it to do but that's okay the point here is that you do not want these things to be failing tests you want them to be tests that are not yet executing and so whatever you have to do to do that whether they're skip tests in the testing framework that you use or unimplemented test whatever it might be you don't want to get a false signal that a test is failing when you've yet to implement it the other thing is you so in this case we're dealing with a feature we want to build a shopping cart right and so this spec is going to describe our shopping cart and it's going to describe it from the standpoint of the behavior of the shopping cart in a manner that might be familiar at least at first to our client and it's not because we're gonna share this with the client in fact that's a that's a bad idea it comes from there's a branch of behavior driven development and a style of test-driven development where you actually you know you let your client look at the tests and you do tests together up I would have not had good experiences with that maybe you have maybe maybe I missed something but I don't recommend that if this is for you but what you want to focus on is writing out the behavior that your code has to implement not the implementation details of the code so these descriptions here are not about you know talking to a database they're not about you know any really detailed level or specifics about certain kind of branching logic or anything it's really plain language simple you know it's a shopping cart you need to be able to add an item remove an item update an item's quantity list the items and then calculate a subtotal price so this is just the behavior that we would expect to see in a shopping cart and you should know this going in so you should have a sense of what it is that you're gonna build and you don't have to worry about knowing how you're gonna build it that comes later so let's jump in and I will show you how I would approach these kind of tests and there's gonna be things in here that I think are going to surprise you in terms of what you may think test-driven development is and how I'm going to do things so obviously the first things we're going to need to do is we're going to need to import the system word that we're testing and so basically I'm importing this make shopping cart which is going to be the system that I am that I'm testing and that's you can see it's on the right-hand here right make shopping carts I haven't implemented anything yet and my shopping cart my make shopping cart here takes a database parameter and the database parameter is just something that represents a data store where the shopping cart can store and retrieve items so if I had a real database I would actually use the real database in the test when I say the real database I mean a local copy of the database that I can sort of play with a local instance I would write my test so that behind the scenes is talking to the database that's okay there there is nothing wrong with that as long as you're not executing queries that are going to take forever you you will be productive and your your tests will actually be a lot more meaningful because they'll they'll be talking to the real thing in this case I don't yet have database and that might be the situation for you as well and so what I've done is I've created a fake database I've stubbed it out so I have this shopping cart DB and all its doing is behind the scenes it's using a map object and it's just it provides a few methods so find my ID insert list remove update and all of these methods just basically interact interact with that instance of the map and so this will eventually be replaced by an adapter to a real database but the point is the interface be fairly stable so I'm expecting that whatever data store I end up using in real life will expose the same the same interface the other thing to note is that this here this shopping cart DB is not a mock okay so this is not a mock you might call it a stub but it's not a monk and the reason that I make that distinction is a mock is code that actually has embedded within it the ability to do assertions okay and mocks can get you in a lot of trouble so I try as hard as I can to avoid using any kind of actual mock in my code and when I say actual mock I mean an object that within it has some embedded assertions so things like a spy or well in this case I'm using just as my framework so I could use just the FN or just mock and it would create a dummy object for me that I could actually run assertions against and the trouble is doing that is then you end up really testing your mocks and not testing the real thing so like I said my first time my first best bet is if I have a real database use the real database my next best thing is to stub it out with an interface that is gonna simulate the database and so just to go quickly here because we're going to be testing this shopping cart I'm just gonna grab a little bit of code here okay and so boom and so what we've done here is so we've got this cart object that we're going to reuse and before each of my tests I'm gonna go ahead and make a new dummy database object and then assign the cart to a new instance passing in the dummy database and so what this is going to do is it's going to ensure that the tests are independent of each other in terms of each time it's going to use a fresh database and so we won't have the one test polluting another test and that's really really test independence else is something else that is a little bit misunderstood and and I'll show you in a second aware where that some confusion comes in so let's let's go ahead and let's implement this first task so hold on I'm gonna save this first and make sure then break anything okay and so the first task that we need to implement is you know it adds an item so we're gonna remove the to do from here and then pass in a callback and because dealing with this kind of code is going to be usually asynchronous so we're gonna make this async and don't get too hung up on the semantics or the syntax of the JavaScript here or of the Jeff's framework if it's something that you use great you might learn something but if you're using a different set of tooling don't worry this is not about the specifics of the language over the tooling okay so how do we write a test for whether or not the shopping cart can add an item and so first of all where are we in the codebase here what are we interacting with so there's no UI at this point I mean there might be on lock up somewhere that someone made but this is not the UI this is not a web service or a restful endpoint and this is not some database adapter so what is this exactly so this is an object a plain JavaScript object that is going to encapsulate all of the business logic of interacting with a shopping cart so it represents it's an object that represents the domain concept of a shopping cart within our application and this is where I only start and this is the the place from which I like to test and the reason is because this is where you're going to discover that unforeseen complexity so remember I said with things like if it's a problem because you're using some UI framework that maybe you're not sure how to do something in you can google that if you're using some database that you're not sure how to do something in you can google that when you're trying to accurately represent the interactions required for your application based on the business and the logic and the particulars of your business that's gonna be impossible to Google because it's going to be specific to your particular circumstance in your particular application so really important that that's where you start because that's where you're gonna uncover the hidden complexity and what I'm trying to do with this workflow is I'm trying to take these tests and turn them green as quickly as possible so now if I if I write my test here it's gonna look like this we need an item of some kind that we're gonna have to add to the database so we're gonna give our item an ID just something random and a name we'll call it the code master 3000 okay and then maybe a price and usually prices in like pennies so maybe it's 39.99 this thing I don't know what it is I mean I'm just making it up right so we have this this item right and then what we're doing is we're gonna pretend that the shopping cart module already existed that this shopping cart object this cart thing here has already been committed so what would it look like to add an item to this cart so I'm gonna say we're gonna do something like cart dot ad and then we're gonna pass in our item so that seems like a sensible API to me and now the question becomes how do you test what do you assert to make sure that the item has been added to the cart and so the tendency with a lot of TDD that I see out there is oh I need to reach for a mark or I need to interrogate the the database directly or something like that I'm gonna say no what I'm gonna say that you should do is you notice here there's a later on we're gonna have to have a method that lists items and so if you were running this code from the perspective of the consumer of the code what would the consumer of the code expect to be true when an item is added so I would argue that once you've added an item to the cart the consumer of this code would expect that when you list the items that the item you've added appears in that list and so I'm gonna suggest to you that the way to the way to test this is to do exactly exist consume the code exactly as the user of the code will consume it to make that that sounds very complicated to make it super simple what I'm saying is we should just go ahead and assert that when we do cart dot list maybe list items that that's going to return you a collection that contains the item that we're looking for so again because I think this code needs to be asynchronous we're going to make this Anna wait and so we're gonna say and expect cart dot maybe we'll say get items cart get items and we're gonna have to await that as well and we'll say to contain equal our item and so again don't get don't get too hung up on this the specifics of the the jest library unless you use Justin and you're interested in it and the point here that I'm making is it's perfectly acceptable to call two methods of your object in one test so even though this test is about testing the ad I'm going to tell you that it's okay to call the get items in order to test the ad because by virtue of this before each up here creating a new card each time I know that our tests are going to be relatively independent yes it's true if get items or ad breaks then this test will break but think about the real scenario so in the real world of this code if these things are linked so if one of them is not working properly your app is not working properly so that's actually okay and it's a benefit it's a good thing that you're using these two so now if you see down here we've got ourselves a failing test so we've got to go ahead and implement it so let's let's do that and so this will have to expose an ADD method and it's gonna have to expose a get items method and then we'll implement the add method function add item and this is going to be an asynchronous and then we're just gonna return Davida insert item and we're gonna have to do an async function for get items and that is going to have to what's it gonna do this with everything okay so that's just gonna return our this list function so we're just going to return this and we'll return DB dot list that's it okay and so now we have a passing test I'm just doing the absolute minimum that I need to do to get this test to pass so I'm not this is probably not the final version of these functions we're gonna have to probably add more logic here but I just want to get to Green as quickly as possible hey it's bill sewer here so when I originally recorded this video I coded for a lot longer but I think you get the point of the workflow that I'm trying to recommend if you want to see a more in depth video specifically about my approach to test-driven development please leave a comment below and I'll do my best to get back to you okay well this has been an episode of mastery Monday thank you so much for watching I hope you've gotten value out of this don't forget to subscribe and hit the notification bell so that you never missed a future episode you can also get my newsletter at WWF as recom I look forward to seeing you there have a great day [Music]

Channel: Dev Mastery

Views: 14,293

Keywords: DevMastery, Dev Mastery, Bill Sourour, JavaScript, Codiing Workflow, Code better, Sourour, Developer Workflow, Test Driven Development, Coding Workflow, programming, coding, javascript (programming language), programming workflow, coding tips, software developer, software engineering, web-development, software engineer, programming tips, Ultimate Coding Workflow, web developer, development, code, Ultimate Developer Workflow, dev workflow, best way to code, best way to write code, TDD

Id: nK3LP-pn_08

Length: 20min 26sec (1226 seconds)

Published: Mon Feb 04 2019