Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
so has on said I'm Trevor Landau in your time someone the mobile team there and here to talk to you today about test driven back on development I've also want to thank folk who and sponsors or give me this opportunity to speak here so the first time
speaking it's really exciting ah so I'm just going to give you a little background on what we're going to be talking about let's imagine we have a brand new app your boss sits down with you and says hey this is what we're going to build
so you start building the project you write code and then you test the browser see what's working I'm sure it's working the first time you check it out continue to build a project technical browser not working so see where the code is failing you'll
fix the code still not working we'll go back and fix the code all right so it's fast forward a few months and projects ready go development or production brother and everything is going well so after this couple let's go by and a lot of users are
using the site and something they want these new features and your boss comes you it says ninety percent of our users are asking this brand new feature i need you to implement it let's get it in now so a lot of work is done and say a backbone model so
you make a change to your model and then a little up the app and you realize it's not working anymore so you took out your code and you say this looks alright still not working and then you look at your stack trace in your dumb console step through and
say oh ok we have problems here so right this is a real problem so you're like what what is going on I have no idea what is breaking up we get around this we can fix this mostly fix it anyway how through testing so what exactly is TDD so TDD is test-driven
development and it's a direct quote from wiki a software development process the idea is to write our tests followed by writing code and then we refactor here's a basic work flow chart in more detail we can run a test for a specific unit I'm so
let's imagine we have a backbone model that we're testing and we create our model and that's all we have so now we go write our test we can say this model should be doing this thing that should be doing this thing and etc once we have that in place
we can run our tests and they should all be failing because we haven't written any code yet after that we write the minimal amount of code to get this step to get these they get these tests passing once they're passing we actually go back and refactor
the code to make it work better so y te kind of explained it already however it sounds like coding is going to take a lot longer but as we can balance this out because you're going to spend a lot of time debugging code but it's not tested TD forces
you to understand the problem before you actually solve it it also encourages smaller units of code we find yourself writing large functions it's going to be difficult to test because it does so many things and this in turn reduces debugging efforts Co
becomes easier to understand also because of how you write your tests so it's in a way self-documenting so how to do TDD you want to begin by employing a test runner the test runner provides functionality for allowing you to write in that test these functions
has specific verbiage to write the test there is a behavior driven development or BDD way to write the tests that I prefer to use because of the readability and JavaScript there's a ton of frameworks most popular ones are mocha Jasmine cute it probably
alternities so how do we get started writing a test some test Suites come with assertion libraries the social I breezes we actually test if a return value from some function is working on the sum required to include yourself of course you could always write
your own here is a basic assert function this expects a boolean value and some sort of error string that will get outputted the boolean value is not true and we simply throw an error and you can you can use this in your code and it's actually quite useful
instead of actually saying if some value then throw an error so to give some credit to to do NBC it has popularity so a lot of people know what it looks like because when they jumped in the backbone this is where they went most likely if they've done it
recently anyway and it's small and easy to understand what does not work for a large scale app that is true oh so it seemed like a great place to do some testing and so I've written tests for the backbone to do bc f as i mentioned before there's
some frameworks i'd like to use mocha this allows you use TDD or BDD Burbage but just as a reminder i'll be discussing the bde brooklyn style so as I said before we get a set of functions that's employed by the that's provided by the test runner
and the first one is described described is a basic function that accepts a string and a function you have to worry about functionality under the hood the first bit is describing what exactly we are testing so in this case we're testing a to do model and
we just say to do model and that is it but you don't necessarily always want your assertions described in one block so we can actually nesstar describes and this is really useful for readability in terms of we have a to do view and I'm testing the
initialize method the way I prefer to do it is dude usually do a dots represent that it's a method of this class and not class instance or a class static method or something oh but these going to actually be nested infinitely but that's the best practice
says you should probably not go two or three levels deep and get like that callback he'll look but it's a little more straightforward so the next function is before after look the purpose of these functions is to prevent code from bleeding into another
test so let's imagine you have a large data set they were trying to test your code against one of the tests may actually modify this data but it needs to be set back to its original state for the next test so within before neech you're going to you
[ ... ]
Nota: se han omitido las otras 3.054 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.