Side Effects: Another Test

00:00 Currently, this is kind of a useless test because, as we saw when we ran it without setting the .side_effect, it raised the ConnectionError automatically because I don’t have the holidays API running on my machine. But let’s set another side effect.

00:16 One of the other exceptions that come with this requests module is a Timeout,

00:23 a Timeout meaning you make a request to a server, the server—there’s something wrong with it, or it’s just really slow. The response you get back might raise a Timeout exception.

00:37 As we saw when we first made this GET request, it returned a ConnectionError, or rather it raised a ConnectionError. It didn’t raise a Timeout error, but we can actually test the Timeout error by setting a .side_effect in a test.

00:54 So let’s go ahead and copy this, we’ll copy this test here, and we’ll make a new one called .test_get_holidays_timeout().

01:09 And then here we can set the .side_effect to not a ConnectionError, but a Timeout. And we’ll say it raises a Timeout

01:20 when we call get_holidays(). And we’ll go into the console and let’s run our tests once again.

01:28 And there we Ran 2 tests and they both succeeded. So this shows that you can use the .side_effect attribute to assign a side effect of a mocked function, like the .get() method. Right now, like, you might not see the value of using .side_effect.

01:48 It almost feels like you’re cheating in a test. Like, why would you just test, you know, make the .side_effect Timeout and then it should just verify it—like, wouldn’t this always raise a Timeout if you set the .side_effect to a Timeout? Well, yes it would.

02:04 But we’re going to continue exploring .side_effect a little bit more and hopefully things will make more sense and you’ll see how you can use it to write better tests.