Introduction to test-driven development with Angular

hi there in this video I will show you how to use test-driven development approach with angular so there are only three steps in TDD first you write the test and it should fail then you make this test pass with the most straightforward and easier solution you can come up with the approach that allows you to make that test pass as quickly as possible and lastly we refactor your solution into something more robust while keeping the test passing now let's get started at this point I have set up an empty angular application so let's imagine that this will be a to-do style application where you will be able to view existing to use and add new ones to demonstrate how I use test-driven development I will build a feature that will list existing to use let's start by generating a to-do list component using command line I'll put it in the components folder and call it to-do list then I start the test runner that should show all tests passing now onto the very first step of death driven development which is to add a first failing test I navigate to the test file of the to do list component I rename this default test to describe my first real test which is to list existing to use should list to deuce or rather should show to deuce then I modify this existing expect statement to assert that the component shows a number of expected to do's we use native element over the fixture object to query the rendered HTML of the component to search for the elements that we expect to be present which is to use so we use the query selector old method and we search by the class name a to do and then we'll look at the length of the returned array and we expect the length to be let's say 3 - dues and that's our first test since I've written it using test-driven development there is no code behind it to make it fast so if we look into the console we should see our first test failure and in fact it does fail saying that in our assertion we expected there to be 3 - dues or rather three elements with the class to do but we got zero and as I mentioned there are only three steps in test-driven development and I've just completed the first one which is writing the first test the next step is to make that test pass with the most straightforward simplest solution so let's open the template file of the component and see how we can make it pass so the simplest solution will be to just list all the - duze here in template directly and don't forget to add the class by which the test is asserting that the two dues are present in the template as three of them and these are our three - dues so let's look add the test and it is passing and now I have just completed the second step in test-driven development which is to make the test pass the third and the last step is to refactor your current solution to something more robust while keeping the test passing so let's go back to the editor in reality that's not how web applications work the list of existing - dues will likely come from some kind of API service from the backend which will require making an HTTP call and in angular HTTP calls are delegated to services therefore the to-do list component should use some kind of service to fetch these to use so let's add a service using the command line open it in another tab navigate to the application then generate the service put it in the services directory then inject the service into the component once the component has the service to fetch the to Do's we can put it in the own init method where the component would ask the service for the two do's and save them into a class property so first of all let's declare that property here and call it to deuce will default it to an empty array for now and then use that property to save the two dues by calling the service it's highlighted because the method doesn't exist in the service yet so let's go into the service and add that method it will return an empty array for now so at this point I'm not worried about how this service will fetch these two dues exactly that's not my concern I will mark this method during the test so I don't really care what's happening here during not the test run but during real execution now back to the component template to display the list of existing to do saved in the class property the template needs to iterate over the list using the ng for directive like so make sure that the class property is still present because that's how the test is asserting the presence of the elements in the template now let's check the test and now we see that it is failing oh it's actually failing because of the parsing error oh this should be all then check the test again and now it is failing with an appropriate message saying that the assertion expects there to be three 2d use but we only have zero we have not that's because in the controller of the template we are getting the list of - duze from the get reduce method of the service and if we look inside of it it returns an empty array so when we go into the template it iterates over an empty array and doesn't produce any of the 2ds that's why the test is failing to simulate the scenario required for my test where the service returns 3 - duze i need to mock the return of the get to dues method of the service so let's go to the test and first add a variable where I will store the reference to the service where I'm going to mock it then grab the reference from the testbed then we'll use the Jasmin spy on function to spy on the get to use method of the service and then have it returned or expected 3 - dues make sure that the the tech changes call happens after we set our spy now let's check the test and it is passing it is passing because we spied on the get to this method and told it to return an array of these three two DS and during the component execution that's in fact what happens the d2 dews got saved into this to use property which was used in the template to iterate over and create the list of T DS at this point have completed all three steps of test-driven development I utter the failing test I implemented the simplest solution and then I refactored it as you might have guessed this is just the beginning I still need to implement the HTTP calling logic in the service method before I can test that the whole thing works correctly to do that I would start a new cycle of test-driven development I would go into the test of the service and create a new test where I would assert that when I call the get to DS method it properly uses the HTTP service you call a certain URL and then returns the data in the expected format to save time I won't do it in this video instead I just hard code some random values in the return so that I can test this in the browser and when I open the browser I see that it works notice how this is the first time I opened the browser so far when you stick to TDD it is not uncommon to build large chunks of functionality and only then open the browser and check that everything works and do some adjustments I don't even bother with any of the styling before I get the functionality right only then I start adding styling classes CSS tweaks grid layout and so on in this sense test-driven development allows me to focus on the most important thing from the get-go which is good user experience and not getting distracted by irrelevant things such as how to fetch or store data in the backend or what shade of blue this button should be another benefit of TDD is that there are only three steps so when I returned to my coding I always know where I left and what to do next next benefit is that TDD makes it easier to create a better architecture because it constrains me to write only the code that's absolutely necessary to pass the tests and no more it also helps me to see where to start breaking things down into more components or services or where to use state management next when you write the tests in the way that describes the desired behavior of the component it creates a living executable documentation for your code so instead of figuring out the inner workings of a component or a service you can just glance at the tests and get a quick idea of what it does and how it works next when you have tests that assert against the expected behavior of components it is so much easier to refactor them for example as long as my test for listing two dues is passing I can completely refactor the way those two dues are fetched prepared or filter it for the display and still feel confident that everything works correctly lastly writing tests first makes better tests in general if tests are written after the code it is too easy to miss some important functionality additionally the tests that are written after the code often assert against the implementation not against the expected behavior so these tests are harder to understand also they break as soon as you change some implementation detail in your code even when it's not related to the expected behavior and because of these reasons I prefer to use test-driven development for all my coding thank you for watching this and I'll see you next time

Channel: Irek Mirgaleev

Views: 4,280

Keywords: angular, test-driven development, tdd

Id: oevY4WE1lnw

Length: 15min 45sec (945 seconds)

Published: Thu Sep 20 2018

Reddit Comments

[u/irek02]

I used TDD for most of my Angular (1.x and 2+) development since 2015. In this video, I attempted to demonstrate how I do it and why it is so beneficial. Please check it out and let me know what you think. Feedback is very welcome. Thank you!

[u/rustprogram]

I would like to run tests on gitlab ci. How do I do that? Do I have to use custom docker images?

[u/FuzzyConflict7]

Thank you! I do TDD with React and other languages, but have struggled with Angular. Saved your post. Super excited to check this out