Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
all right good afternoon everybody thank you for coming I'd like to introduce Ned Batchelder who's going to talk about getting started with testing hello everyone so this talk is starts at 1:40 but the printed program says 1:55 so there's going
to be some people coming in late and you can all make friends by piling up with them later and explaining what they missed in the first 15 minutes I'm going to have a lot of code on the screen it might be difficult to read your two options are to move
forward or to use the bitly URL at the bottom which will take you to a page on my website which has all the slides in the code and even the text if you want to follow along so my goal here today is to show you a way to test your code I'm assuming that
you have not written tests before and you are test curious let's say and that you want to figure out how to do it so I'm going to show you a way to test code there's lots of different ways to do it and if you talk to testing experts they're
probably going to tell you that this is all the wrong way to do it maybe but this is a way to get you started I want to remove the mystery from writing tests first a little bit of philosophy about this why test testing automated testing is the best way we
know to figure out if code works what I want to hope when I'm trying to show you in this talk is to look at tests as a solution to a very important problem that you have you have written some code and the problem you have is that you don't know if
it works and tests are the solution to that problem some people approach tests as a checkoff on some sort of form that they need to complete before they can go home at the end of the day it's just sort of paperwork to get done and that's the wrong
way to look at it you'll be very unhappy if you write tests that way testing is a very serious problem too it's a serious solution to a very serious problem and if you approach it as such as real engineering you'll get a lot of benefit from it
it will save you time because you won't have to go back and fix problems later and it will give you better code because the tests will actually help you write better more modular code to begin with most importantly for me it removes fear from the development
process if you've ever approached a large piece of code and had to change it and thought that you were certain things up and make the code not work anymore testing is a way to make sure that you will not do that anymore it turns fear into boredom as a
way that I've heard it put and the other way to think of it is that debugging is very hard but testing is easy so testing is a really good way to write really good code this is most developers first impression of testing they know that they should be doing
it but they're not doing it and so they feel bad and and just like our poor developer here they are paralyzed by this feeling of inadequacy and uncertainty and doubt about what they should be doing and and and they feel bad and I don't want you to
feel bad testing is hard it's a lot of work people and by people I mean you will not want to actually do it but it pays off so if you approach it as an engineering task to solve a problem that you really have and that you want to solve it will work out
for you the reality is that the universe is a chaotic place so here's another poor developer she recognizes that the universe is full of chaos that is trying to attack her code okay you know how it is you write a program it seems to work great and a week
later who knows what's happened to it some gremlin has gotten to it and it no longer works tests are the defense against this our developer here has a spear and a shield those are the tests that I'm going to teach you how to write them and use them
alright our goal for this talk is to get these two developers happy and confident at the end so the road map there are three main parts that we're going to talk about today the first part was we're going to grow some tests organically we'll take
some real code and we'll just start testing it's sort of ad hoc making up as we go along and talking about what we like and don't like about the way those tests are coming out and then we'll the main piece of the talk is talking about the unit
test library in the standard mount in the standard library that is the way that the right way to write the tests and I'll show you the some bits and pieces of the unit test module and show you how to use them to build your tests and then I want to get
into a kind of an advanced topic mocks which is something that you don't often see in a novice talk but it's a really really powerful tool for making your tests much more powerful and flex so let's start from first principles and grow some tests
so here is our stock portfolio class and again if you can't read the code there is a bitly link at the bottom bitly slash PI test zero where you can see the code so this is a stock portfolio class it's very simple we define a class it keeps a list
of tuples named shares price you can buy some shares for a certain amount which will append that stock lot to the list and then later you can ask what is the cost of the portfolio the original cost which is simply the sum of the shares times the price for
all the stocks in our portfolio very simple code how do we test it well the first test is excuse me you just launch the interactive interpreter and you start filling around with it you make an empty portfolio and you can see that its cost is zero and then
you can buy a hundred shares of IBM stock and you see that the cost is gone up and then you buy a hundred shares of HP stock and the couple the cost has gone up some more so this is really good so the good thing here is we're testing our code let's
be honest there are developers who have not gotten this far right so right off the bat let's just congratulate ourselves that we are actually testing our code but the bad thing is that this is not a repeatable process if we change the implementation we're
going to have to go and do this again and we won't remember what it is we test it and we'll probably miss a case and that's where the bug will be it's also labor intensive you have to type this out every time and you don't know if it's
right you're going to get out your calculator and see if the arithmetic works out right so let's fix some of those problems the second test will write a Python file and we'll import our portfolio class will basically do the exact same things we
just did in the interactive interpreter we'll print out what the cost is at the empty portfolio and then after we buy a hundred shares of IBM and that's good and we can see that you know this price has gone up for the IBM stock and then after we buy
the HP stock it goes up so that's good we're testing the code it's now repeatable we can run that Python file anytime we like it's very low effort it doesn't take much to run that file but we still don't know if it's right we have
to look at that output and you know is it right that it comes out two to one two six three you have to get out the calculator again all right let's add some more to our tests so now here what we've got is we've got a portfolio cost where we print
out what it should be and then we can print out what it should be and we can print out what it should be and here we can see that it's printing those I apologize for this code going off the side of the screen now it's even better we've got repeatable
tests with low effort we've got it's better it's better because we got explicit expected results we still have to check the results ourselves here the line of code if it were wrong we just have to look and see if the two numbers were the same or
if they were different right the computer isn't telling us whether the number was right it's just showing us the actual result and the expected expected result so again let's add a little bit more to our tests keep in mind these are not the way
you're supposed to write tests okay this is you exploring the problem of writing good tests I'm going to show you with unit tests how to do this the right way but here now what we've done is we've taken our cost and in addition to printing
a message about what it should be we use an assert statement to assert that the cost should be zero if you haven't used the assert statement before it takes a condition and if the condition is true it simply carries on executing the next statement but
if the condition is false it raises an exception so here we can make an assertion that the cost must be zero because our tests are passing the assertion never happens so now we have repeatable tests with low effort we have explicit expected results and the
results are checked automatically good the problem is that if the test fails it will actually throw an assertion error and the tests will stop this blue code is actually incorrect there should be an assertion error there so if one of those assertion fails
the entire program will stop and you won't run the rest of the tests so if you would this were a real program that we're doing many tests you'd have a hundred or a thousand or even 10,000 checks to make if the second one failed you'd never
find out about the rest of them what we'd really like is for each check to be run completely independently so as you can see this is getting complicated right if we wanted to approach that problem of how do we make the tests run independently of each other
[ ... ]
Nota: se han omitido las otras 4.795 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.