[MUSIC] As we look further into the anatomy of RSpec, in this lecture, we're going to look to thin down our example blocks. Breaking down our compound tests into isolated tests to better express the requirements and our ability to meet those requirements. We'll cover one-liner examples, where the power of the matcher really starts to shine. And then we'll take a look at the subject object, if we want to reduce the verbosity of our examples a bit further. Okay, but let's say I had an error early on in my block. And let me purposely cause an error. Now, if I run my test, it's going to report the error that I purposely caused in there, but it's not going to tell us anything else. All our other expects do not execute. So what I can do to fix this is I can go ahead and separate these into separate blocks, separate examples. And say the first one is, well, it's going to be persisted. And the next one, it's going to have a name. And the last one is it's going to be found. And let's see if we can improve some of the English. Okay, if we rerun our tests, it'll be a little noisy, but it'll be able to figure this out. We start out with a failure. It got inserted, but because we inserted an error, it failed. But that didn't cause it to stop. And then in the next test, the transaction began, it inserted the record, and it ran the tests. And in the third one, it started the transaction and it ran the test, and each time it was able to roll back. And so we're able to get more information. Three examples and only one failure, we've got some isolation going on. So in concert with our separation, let me fix this, these typos. We've separated things into blocks. And we can go a step further. We can just get rid of all the text. Now here's where the power of the matcher comes in. The matter is going to be used to express the status of the test, or the spec. And it probably would help if I turned off debug. And now if I run my test, what you'll notice is that we have our created Foo, and it says it should not be persisted. It should equal test, it should not be nil. So where did that text come from? It came from the matcher. Well, this one is a customized matcher that comes from, I guess, I would assume Active Model. And you see how this is decent English. You know, it's talking about, it should be persisted. This matcher is just string equality. It really isn't telling us any business information, it's not saying like it has to have a name, or a name of a particular value. And this is just a value of evaluation, be nil, it's not saying it can't be found. So when I was saying earlier about custom matchers, if we want to cut down on the amount of documentation that we type into our tests, we can build this custom marchers, which I won't go into. But we can build custom matchers that are for a particular business purpose that will kick out the right information. Okay? Let's at least do this thing, passing in all colors. So persisted equal to test and not nil. Then we can notice that we have a bit of a shorthand going on here. And let's go ahead and duplicate this. And since everybody's referencing the same foo, what we can do as a shorthand is just go ahead and refer to what's being created as the subject that's under test. So instead of expect foo to be persisted, we'll just say, whatever the subject is is expected to be persisted. And then if we actually have to refer to the subject, we can just call it subject. Okay, this isn't any fantastic capability, but anything that allows us to shorten up or make our tests more succinct in expression, there's some value in that. But you'll notice that they're identical. So in summary, in this lecture, we looked to make examples a bit more concise. We broke down our compound example into individual, and then we even went one step further and even took them down to one-liners. Now, because our matchers were not targeted at our business domain, they gave pretty generic responses. So it would be questionable whether the one-liners were actually appropriate in our case. Or we can go back to an example block, where we had the ability to express the details of the requirement in a string. We took a look at subjects, where if we're trying to focus on a particular object, we can make that object our focus, be a bit more terse in the expressions within our examples. So what's next? Well, let's wrap up this anatomy discussion with pending examples and lazy/eager let blocks.