Before/After Hooks & Async Code

[00:00:00]
>> Steve Kinney: The other thing that I'll kinda just, we'll see it later, but this goes into the not wanting to lecture about too much, and then kinda get into it. Is this up here, you see that I'm doing it in every test, right? And so there are some helpers kinda built in where you can do stuff before each.

[00:00:22]
>> Steve Kinney: And in this case, what we just gotta make sure is that we have it in scope.
>> Steve Kinney: There are some other ways to do that. But you could have something that you run before each test, right? So you find yourself doing something repeatedly, you could theoretically do before every test.

[00:00:40]
I'm gonna argue to you, and we'll kinda see this, that for some cases, if we're gonna set up some environment where we mock out the network, short do that, or restubbing stuff, fine. But here's the issue, I did this, and now I don't have to make the character every time.

[00:01:04]
But also, when I stare at a test, if this test file got big enough, it is really unclear where that character is coming from. And if I wanted a test where it is a slightly different character, well now I have to weirdly override it. And so this kinda went before what we said earlier, which is there's a principle in our code, not to repeat ourselves.

[00:01:22]
But in our tests, the act of trying to abstract stuff and get clever takes away from clarity. And a lot of times that reduction, you don't need your tests to be clever. You want your tests, even if they're repetitive, to be dumbly simple, because if they're failing, you don't wanna be in there right now.

[00:01:39]
When you're writing the test, sure, sure, sure. But later, you just wanted to stay green all the time. If it turns red, you wanna be able to triage it real fast. So can you do this? Yes, should you always do it? I'm gonna argue, probably not, right? But there are use cases, and we will see it, but I have done my due diligence at that point.

[00:01:58]
One more thing that maybe in a previous life would have necessitated its own section because it was hard. And we kinda saw it earlier, but it's a lot easier these days is dealing with asynchronous code. Coz what's the one thing that makes everything in JavaScript harder? Anything being asynchronous.

[00:02:18]
And it used to be you had to do a bunch of whole bunch of crazy stuff, the test function would take a done callback. You would call the done callback. After all, your asynchronous thing was done coz you used to have past callbacks and the callbacks and I heard you callbacks, don't worry about it.

[00:02:35]
Coz we saw that if we never get to the expected. It doesn't fail, our tests are true. You can do stuff like this. Honestly, the answer to this now is simply most the testing suites, if that test function is an async await function and you await everything like you're supposed to, it just works, right?

[00:02:58]
And so you might see things in your code base where there is a done, passed in here and called these days you don't necessarily have to worry about it. You might come across it, but if it's asynchronous function and you're using async await, everything works. Life is easy.

[00:03:14]
If you're forgetting await, things will break. Coz either this value will be a promise and not what you thought it was, or something along those lines. But you will see a bunch of different other theatrics for asynchronous code. But I would say for most new tests, as long as they are asynch await, and if you come across a test, it's not you should just refactor it, right?

[00:03:34]
And so previously, if we wanted to take this example real quick and just show you. Just put it down here, we won't even run it. If this wasn't a sinker weight, ignore the red squigglies. And this took a call back, you would have to do something.
>> Steve Kinney: And then the callback would go in here.

[00:04:02]
>> Steve Kinney: The problem is, again, coz the test would just go on, it would pass even if this failed, because there was no expectations. So you would take this done, and you would call it at the end. So if you see code like this and it makes you sad.

[00:04:18]
It could just be single weight and everything can be easy again, right? That this thing which you'd have to squint at could just be.
>> Steve Kinney: Well that was a lot more hitting on undo than I expected. This and that will work these days. So you might see the other thing from older tests, but, wait, now it's good.

[00:04:46]
In this case, that is all you need to do to really worry about asynchronous code these days.