Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
it's my great pleasure to introduce all of your crummy re all the way from Switzerland give him a hand ladies and gentlemen Olivier yeah olivia is the co-founder of bug buster incorporated and this is going to be one of the highlights of the show to watch
out for this this is a session on automated testing and he's just going to walk you through the product that he's built for it and show you some cool tricks that he can do with it I'd like to thank us with Nick's for bringing him down from
Switzerland and the anglers is so Barbara and Johnson mame for getting us in touch with him he's already done one great workshop yesterday and are you you're about to see what what he's built uh-oh do you love you thank you very much thanks for
the intro and thanks for having me here it's a great pleasure to be here in India and see this driving community as as he said I'm a co-founder of bug buster I've been working with the web and with JavaScript for a long time now a few years ago
I decided that I was actually sick of JavaScript so I was like okay let's do something else let's do a PhD some serious things and obviously it worked very well because you know Here I am at the JavaScript conference speaking so anyway I did the research
in software testing and it ended up in the creation of bengbu sir which is a startup based at in Lausanne Switzerland we're spin-off of the school where I i made my PhD on our goal is to help you guys build better applications and for for that you need
tools that will basically reduce the effort of testing this application and increase the coverage so that you can produce the quality applications that your users expect so back to the title of my co of my fault generating tests from codes actually yesterday's
talk was automating automated tests and was pretty much the same idea so if I talk about automated testing anna and i give you the definition actresses from from wikipedia automated testing is about controlling the execution and of the test automatically obviously
this is much better than doing everything manually right so let's let's look a little bit more about you know what this means you're going to use tools like sanam webdriver if you doing front-end development or just mine if you're doing front
end or back-end development for javascript and in fact with what you're gonna do is you're going to start by writing one or more test cases a test case is a piece of code it's a script that explains basically what your code is supposed to do you
know what are the expectations right then you're going to run the tests hopefully you're going to find some bugs so you're going to debug your application and then you know once you have once you have no more breakage application you're going
to release your program you know everything's going to work nicely you're going to be happy and you know you can you can be able to go do something else then when you write new code you have a new version of your application you have a new climate
well you basically start the cycle again letting more tests running more tests and so on and so forth well that's all very nice but the thing is if you look at your program this is sort of a graph showing the control flow of your program with the if statements
you know leading to different blocks of codes it's actually going to be very very big right most non trivial programs are going to have a huge control flow graph sometimes it's actually infinite and when you write the best case what you're doing
is you're essentially encoding the expectation for one path right and then if you're lucky that path will lead to a bug and you're gonna have you know you can be able to debug the program but if you're not so lucky well maybe you should have
written another test case because bags were somewhere else and then you know you be you'll be missing some some problems so if you look at how automated testing really looks in practice I mean for being in real life well you write your test cases then
you run the tests then you debug your test because test are actually more code right then you debug your app then you release and then what you fix the bugs that were reported by your users right and well because you be we're basically code with your pants
down you don't want this to happen again so you write additional test cases it and then you repeat the cycle for every new version of your new common threat so that's exhausting and that's why you know testing has this reputation of being so tedious
our goal at back buster is to basically help you do better than that so how can it can we test better or faster first idea use static analysis we've all dreamt of having a great idea who will basically underline your code as you type it on basically tell
you where the bugs are right so studying analysis is the technique where you basically analyze the source code without executing it and well one could imagine that with such technology you would be able to do that you know and find the bugs before you actually
run your code in JavaScript there are already some very cool static analysis tools like you know just hint or jeseline's if you're not using them you should definitely definitely do that they'll you know they'll tell you about a lot of errors
or syntax error and that kind of stuff there are other tools that use static analysis like closure or egloff ideas for four different purpose for basically compelling or minifying your coat on well that's all that's all very good and useful but the
problem is that static analysis is inherently in precise especially for javascript which is a very dynamic language it's very hard to know what your code is going to do without executing it I just think that state statement here is 4 is greater than 0
and I want to analyze it to make sure it's correct and there is no bag well I have to figure out what type what type fool can be could be anything is doing a number of function then I have to figure out where foo is pointing to so that I can basically
have an idea of what value it can take and then I have to figure out what this statement is supposed to do in the first place right so you can make assumptions assumptions about all of that but it's going to be difficult to be very precise it's been
[ ... ]
Nota: se han omitido las otras 3.137 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.