Vue NYC - Component Tests with Vue.js - Matt O'Connell

how you doing everyone I'm Matt O'Connell I'm a JavaScript developer at Adobe currently I'm working on the Adobe portfolio and behance teams right now we're in the process of converting both Adobe portfolio and behance over to view applications so today I'm gonna talk a little bit about everyone's favorite topic I'm sure which is testing UI components so first I'm going to start with the goals of testing why test our applications why write all this extra code even more than a production code often I would say that number one the testing instills confidence it also removes the fear of changing code on a larger codebase so if I'm a new developer or I'm working on a large code base and I'm unfamiliar with the entirety of the codebase and be confident that my change is not going to bring down the rest of the system the factor that I introduced some new code knowing that I'm not going to break the system I'm not going to get all one am number two I would say good testing leads to higher code quality here's a quote that I found in clean code by Uncle Bob Morton it's test a single concept in each test function I find that when I'm doing this it leads to code that's following the single responsibility principle more modular code and writing the test ultimately makes you take a step back and think about what is my production code doing what is the component really meant to do here so an example of that might look something like this I look at a test I see it should display a formatted user name I need to add additional functionality to this component so it should display formatted user name with a custom avatar I then keep going in adding more functionality a little bit of logic at this point the test if I haven't seen it in my production code are leading me to take a step back and think about like what is this component really supposed to do at this point so the third thing is documentation good tests act as documentation dynamic documentation often times we'll write comments around our functions or components but those can end up out of date no one's maintaining the comments sometimes and they can get lost so here we could see we have an add button component it's gonna take in some props a label prop it's gonna admit some events the add event and right off the bat without looking at any of the production code we have an idea of what this component is supposed to do and what its API is so what happens when we achieve these three goals we have confidence to change hi code quality well-documented code ultimately this should lead to developer happiness and then on top of that when developers are happy it's easy for us to create a better product and the customers are happy too so those are all the goals of testing now I'm going to get a little bit more into the specifics of testing view components UI components in general first off I'd say we want to test our component contract and a component contract might be defined as the expected behavior of your component and what assumptions are reasonable to have about its usage so this can also be explained as the public interface of a component component is really composed of a series of inputs in views case it would be props user interaction or lifecycle methods and a series of outputs which would be events and rendered output additionally certain types of tests may test the boundaries between a parent component and the child component so I'm gonna dive into a few examples here first I would say if we have logic in our template we probably want to test it in this case we have a settings bar component we have a button that will display if our logged in prop is set to true so we have a logout button so our tests may look something like this I'm gonna use a vory as I don't know if you guys part of it but it's a well known testing library so this mount function comes from F or yes basically we met mount our component we're going to assert that our logout button exists and then we're going to set our props to make logged-in equal false and we're going to assert that the logout button doesn't exist so it's a very simple test but all we're doing is testing oh these are the four es functions and what we're doing is testing the props input and the rendered output so I'm also going to talk about what's outside the scope of component tests one I would say implementation details we have a square component and it has a square button and when you click on that square button it emits an event with Davis squared version of our number here which is ten this we're again using now from the bore yes we are listening for our square then and we're going to assert that the value can get is important and then we're going to go and we're going to trigger the click on the button itself in this case we're just testing user interaction as an input and events with a certain with certain data as well so you might kind of see a pattern here we're test America points more like a black box we're not testing every function within every method and on testing computer proper use this is one way of testing to know also we may want to avoid testing the framework itself if we passed a prop to our template and there's no logic involved we don't necessarily need to test that view is works rather than travel important we can expect that views framework is covering these cases this is expected out the framework out of the box additionally top validation we're not doing anything special about valuation we're saying we expect some string and we're rating test to say they should want us when we pass a number I don't I think those tests are extraneous that probably unnecessary because this function now he should be tested by a few ahead of the box we should really be trusting you to do so another thing I want to talk about is some kind of two different approaches that component tests we have an integration leg approach where you have a parent component that is responsible for its children components and their children components and it knows how all of their templates are set up and in most details about their on the other hand we have a shallow type of testing which is components more than one level down are not necessarily part of our contract so we're not going to reach into some sub component and assert that it's rendering some character attack so here's an example of a counter for this counter component as a button component sub component which has an increment event it will then increment the count within the banker point pass the countdown to counter display and the integration legs has to be be testing the whole flow basically would be testing that when we reach you reach into the button trigger click on the button within the component and then assert that within counter display it's rendering correctly within the template testimo might look something like this there's an accordion s and now we find the button within our component may trigger it clay and then define a counter display we find the template element with the display and we assert that the text has that obtained from again we don't really or we're actually reaching into both sub components and certain things we're still testing like a back black box where we're just passing in unary or impetus user interaction and our output is rendered output so shallow tests are slightly different for this case of the counter component our shadow tests may be just testing the boundaries between our parent component and its total movements when they have two tests rather than that one integration like test and the test the first nest would test that we're passing the correct pop to our counter display after that we won't care frederik that's just not a responsibility as a parent component and we're going to assert that when our character client receives of an increment event that they permit it increments it's add accordingly again we don't care how it was triggered in shallows SPO reach in and trigger clicks or assert dominance so in our shallow test for our counter we are test testing the boundaries between our counter and sub components and the beauty of this why you would want to test like this possibly is as long as your cell components maintain the same API say they take the same props whether you meant the same events you can easily substitute the mountain and still maintain coverage for your attack employment system so there are a few trade-offs here you can imagine integration tests are a little more difficult to maintain I found that when you change some production code you may have to change several tests and integration life structure whereas the coverage is very high so you feel safe with iteration tests the modularity also is low you can't easily sub out sub points on the shallow side we have a contain ability when you change some production coding AIDS has shades one test may be to medium coverage that are ways to theoretically break shallow tests and time agile attorneys so like I said before it allows you to sub in sub components with some or parent employees for somebody Dennis so if you want to learn more about view testing I would say the next steps might be taking a look into testing view X that's used State management system there's sort of one and it's fairly straightforward but a good next step in leveling up your view testing skills and then I would also take a look at a four es and with that you test results so you testing tunnels is the soon to be official train of test utility library for view it's written mainly by the guy who wrote it or es and it's going to share most of the API so it should be an easy transition from one of those and then snapshot testing the chest this is a different subject conceit OpenSocial talked of itself as well as in to end test with ego webdriver IO for Nightwatch seems you know it's a slightly different type of testing higher level and so hope this has been a good jumping-off point for those in their new to view or new to UI testing in general a couple of questions all right hi so you mentioned that coverage in shallow testing is medium does that mean that you don't place as much weight on coverage percentage as the metric for a body minitest is there a better metric I mean I don't I don't place a lot of weight on coverage like a coverage as a statistic per se but it's not something that's quantifiable but I guess if you are not writing integration tests and you have tons of components people are changing event aims what I could say is that the amount of folks that you get after deployments production [Applause] you

Channel: Vue NYC

Views: 16,146

Rating: 4.9402986 out of 5

Keywords: Vue NYC, Vue.js, code quality, unit tests, single responsibility principle, unit testing, Vue component testing, shallow testing, integration testing, E2E tests, shallow vs integration, Avoriaz, vue-test-utils, snapshot testing, Jest, Nightwatch

Id: OIpfWTThrK8

Length: 12min 58sec (778 seconds)

Published: Wed Oct 11 2017