Jonathan is a Pluralsight Author, Technology Advisor, and Business Leader. As a member of the Chief Digital Advisory team at World Wide Technology, Jonathan is able to leverage his unique experiences and skills to drive digital transformation for his clients.
As a dedicated developer community leader, Jonathan serves on the board of directors for the Kansas City Developers Conference, is a Microsoft MVP, and is a regular speaker and keynote presenter at conferences around the globe.
BDD Style Assertions Alright, so we've got a good understanding of Mocha and how Mocha works and what all the pieces are, we're not quite to the point where we're ready to just wholesale test an application, but we're getting much closer than we were just a minute ago. One thing I want to talk about in this module is our assertion style. We've been using assert., and that's kind of clunky, and we don't really like the way that that feels. We've got a very nice clean feel for our describes and our it shoulds, and all that kind of stuff, but assert is kind of clunky, and so I want to walk through using Chai to help clean up our assertions a little bit, and make them a little bit easier to read and just easier to follow so it flows a little bit better. Now Chai has two options for assertions and for BDD style assertions. They've got expect and should, and I don't care which one you use. And in fact, I'm going to kind of show you both side by side so you can see how that works and what that looks like, so that you can decide on your own which one you like better. And we're going to end with a talk about objects. So right now we've only been asserting whether or not something is true or false, and that doesn't really get us too far. We're going to kind of dig into assertions a little bit more so we can check on both values and objects to see how things work.
Spys, Stubs, and Mocks Up until now we've kept things pretty easy and pretty straightforward and unfortunately that's not the real world. In the real world things become very complicated, very, very quickly. And so what we're going to do in this module is start talking about how we mock objects. And what I mean when I say that is, we'll start passing objects around. And we need to keep track of functions on those objects and make sure that things are called when we expect them to. And when we're unit testing we don't necessarily want to test the other objet that we're passing in, we just want to isolate the thing we're dealing with. And so mocking objects is required to do some of that. Luckily for us we have this cool tool called Sinon that's going to handle all of this for us. And it becomes a pretty straightforward thing, not as straightforward as we might like, but we'll talk about it for just a little bit and we'll get down to the bottom of it, and how all of this stuff works. Let's take a minute, get everything installed, and paint the picture for what we're going to do, and then we'll get into mocking objects with Sinon.
Testing Real Things Alright, we've come quite a ways in this course, and we've talked about a lot of different things, we've talked about Mocha and Sinon, and all of those types of things, but everything up until now has been fairly contrived. And I'd like to take a break from contrived examples and start talking about reality, and talk about things that we'll actually run into every day as we're working. And testing is not always as straightforward as it's been made out, up until now. Sometimes we're dealing with modules that get imported, that I might not have access to, or databases and HTTP calls can be complicated. Databases because we're pulling in and we're using packages that are just imported, and HTTP calls dealing with streams, and we haven't talked about streams and how to mock streams yet. So we might have to deal with that. So let's take a look at some realistic scenarios. They're not quite full blown because I still don't want to get overblown with everything, but let's take a look at some real scenarios that deal with some real things, in a little bit of a controlled environment, so we can understand how you put all of these tools together in practice.