Effective PyCharm Transcripts
Chapter: Unit testing
Lecture: Writing our tests

Login or purchase this course to watch this video and the rest of the course contents.
0:02 So we wrote this test and we can run it and guess what, it passes because we're asserting true, but yeah, that's not really that interesting,
0:10 let's write some actual test. So remember, we're going to work on our core bit over here and it does things like pull back a table,
0:19 you find available tables, given a choice and this is like a numerical value that corresponds to say like Thai food or burgers or whatever,
0:28 so we're going to write some tests and the first one that we want to write is that there are tables available at all
0:35 in the beginning when the app starts, for some food category, so let's name the test that, test_there_are_tables_available,
0:51 nobody is going to have to call this so let's make it descriptive, so let's come up here and create a choice,
0:57 we'll say our choice is going to be one and be super explicit about this,
1:00 we'll say one tables, these are the tables corresponding to choice or category one, so we'll say core.find available tables and we'll give it choice
1:10 and then we just need to do as assert that there are one tables that is that the length of these tables is greater than zero
1:17 so maybe we could be a little more explicit I guess because who knows really what comes back here,
1:22 maybe a query or something, so len maybe makes it a little more obvious. Now let's go down here and one of the principles of testing
1:30 is that basically we want to see the test fail first so let's just do a quick return nothing and run our test,
1:39 we failed, we got zero where we expected it to be greater than zero, right here we asserted the value of that, now it being false,
1:52 it is zero which is false and so on. So let's get that little trick away, this is not a real database
2:00 it's coming out of memory but just to keep it simple. Now we should see our test.
2:05 Pass, awesome, so you can see all the output here that we get from pytest and we have our test there, let's go write another test.
2:14 The next thing that we want to test is that we can actually book a table, not just that they exist, but that we can book them
2:26 so we'll test that table can be booked, and let's go and get the tables, so we'll say tables = core.all_tables
2:36 that's just going to be something to start with and then what we want to do is say come over here and get a single table or selected table or whatever
2:45 is going to be a table of zero we've already asserted that there are some so this should be okay. So here's the table that we're going to work with
2:55 and then let's say we're going to go book it so we'll book a table.table_id so then all we're going to do is that assert that the booked one,
3:10 well we could assert that the thing is there and that it is booked, so we have a table that we got back, it is booked
3:19 and maybe the final thing we'll assert that booked.table_id == table.table_id the one that we booked is actually the same one
3:32 it might not necessarily be the same pointer, but it is the same one it looks like we're working with some funky offset here
3:38 so let's fix that, there we go, okay, so that seems like a reasonable test, let's run it. Boom, it passed, let's suppose for some reason it didn't pass
3:49 we should put not equal here— boom it fails, so we can look at this test run over here a little bit we have a few things that we can do,
3:58 notice you already have the time in milliseconds which is pretty awesome you can sort alphabetically, we can sort by the slowest to fastest
4:06 you can collapse these down like this, or you can expand them out, so if we had it like this we could just go say look at different modules,
4:13 we could come over here and run only the failed test, pretty cool, so we could rerun them again a bunch of times by clicking this,
4:22 or we could run just the failed ones and notice this one is failed so of course, we go and fix it it's failed because we did sort of bad test,
4:33 we run that and now it's fixed. That goes away, there's no more ones to run, but we can run them all,
4:38 there's one other thing here that is pretty interesting, here we go run them all up there, notice this, auto test, watch this
4:51 I probably need to leave that up for that to have any sort of meaning but maybe make it smaller, so let's go over here, to our core
5:00 and let's say we're trying to do an optimization or a non-optimization, I don't know let's define a method called test
5:09 and it takes a t for table or just a table and in here, it is just going to do this, we could say test t
5:18 now this is insane to write, we're not going to say this, like this is not how it would be but watch what happens, notice when I save that,
5:28 it reran the test, it reran it right away, and like oh yeah this is supposed to be table so we could go back and put a t like this,
5:37 hit save, wait a couple of seconds and now the tests are running again and it refactored this and say okay I wanted to say table here, that's cool,
5:45 wait a second and so as you work on your program, the tests are just continuously running, I'm not sure I would really like to work this way,
5:52 I feel like it would stress me out a little bit too much to just have this constantly like running,
5:56 but it is pretty cool to basically have this green here meaning your program is okay and it's just a continuous light of status right,
6:06 that's pretty awesome, let's unravel this because this is silly but it give a little thing to write some extra code there,
6:11 all right, so those are the two— it's still running, isn't it, let's stop it. So those are the two sort of straightforward tests,
6:20 that there are tables and that we can book them, those are the main thing that we can do. We're going to come back and look
6:27 at a slightly different variation for testing error conditions, which is also important in code.


Talk Python's Mastodon Michael Kennedy's Mastodon