There may be a few projects out there that don't require you to write tests to contribute, but the vast majority will, so it's important that you get comfortable with that process as part of your open source contribution. Depending on what you're contributing, there may already be a relevant test file, but in our case, StepsTest.php did not exist before, so we'll have to create a new test file, StepsTest.php. I'm going to go ahead and write a bunch of to-dos which will form the tests that we're going to write for the duration of this episode. And I'm back. Here's the use cases I've come up with. Obviously we want to check that we can run multiple steps, that we can revert steps,

Here's the use cases I've come up with. Obviously we want to check that we can run multiple steps, that we can revert steps, and that we can prevent steps from being reverted. We also need to test that we can run custom logic when reverting a step, that you're able to receive all previous responses in each step, that we can key a response by a given string so that you can easily access it inside the array, and that normal prompts don't allow reverting. So, let's go ahead and fill each of these tests out. It would be foolish to start writing these tests without first seeing how other tests in this package have been written.

It would be foolish to start writing these tests without first seeing how other tests in this package have been written. Let's take a look at the CONFIRM PROMPT test. So they seem to have a fake helper bait right onto PROMPT itself, where we enter an array of keys that we want to fake, that we want to press. Then we perform some form of prompt, and we check the output. So you can see here, they press DOWN followed by ENTER, and they call CONFIRM expecting that the result is FALSE, because obviously when you press DOWN, you go to negative confirmation, and when you press ENTER, that confirms your choice. Is there anything else they're doing?

and when you press ENTER, that confirms your choice. Is there anything else they're doing? Look at this, PROMPT also has a way of checking that output was placed into the terminal itself. No doubt that will come in useful for our tests. It seems then that our tests should be split into three distinct sections. First of all, we FAKE the prompt, then we EXECUTE the prompt, and finally we ASSERT that it matches our expectations. We'll start with EXECUTE and then we'll come back to FAKE once we know what we're defining. Let's call steps. We'll add our first step, perhaps this could be a basic text input.

Let's call steps. We'll add our first step, perhaps this could be a basic text input. What is your name? Then we could add a second step. This could be SELECT, right? So we SELECT what is your language, and I'm talking about programming language here. So we could say PHP or JavaScript. And then we'll add a third step. This could just be a simple confirmation. So we CONFIRM, are you sure?

This could just be a simple confirmation. So we CONFIRM, are you sure? And then finally we'll run the steps. We could capture all of the output in a variable, RESPONSES, and now let's think about how we actually use key combinations to run through these various steps. PROMPT_FAKE, passing an array. Let's give my name, L-U-K-E, followed by ENTER to confirm. Then we're on what is your language, well obviously we're PHP, key ENTER immediately, and then key ENTER again to say that we are sure. Hopefully that works.

and then key ENTER again to say that we are sure. Hopefully that works. So now all that's left to do is assert using the expectation API. EXPECT_RESPONSES, and I'll use the toBe check to create a symmetrical identical array to check against. The first should be Luke, that's my name, then PHP, and finally TRUE because we did confirm. We'll execute the test, and it passes, nice. Let's remove the comments, we don't want to actually send those in our pull request, and let's move on to our second test, which is going to check that we're actually able to

Let's remove the comments, we don't want to actually send those in our pull request, and let's move on to our second test, which is going to check that we're actually able to revert steps. I'm going to copy most of the code from our first test. So we'll take the body of it, paste it in, and make a few changes. Let's say we enter our name and our language, but then we want to go back to step 1. So perhaps under here we could say KEY CONTROL U, KEY CONTROL U, and that will put us back at step 1, meaning that, well, we want to enter this information here again. Luke can become Jess instead, J-E-S-S, then ENTER, and then for the step below, how about we say that she writes JavaScript?

Luke can become Jess instead, J-E-S-S, then ENTER, and then for the step below, how about we say that she writes JavaScript? I know that she's very good at JavaScript and TypeScript. So let's say KEY DOWN, followed by KEY ENTER, and then finally we CONFIRM. That should mean in our responses we have Jess writing JavaScript, and confirmation is true. Run, and it passes, brilliant. On to our third test. We have the ability to prevent a step from being reverted. Let's paste our test template in again, and how about we say that this language question

We have the ability to prevent a step from being reverted. Let's paste our test template in again, and how about we say that this language question cannot be reverted once selected. So REVERT is equal to FALSE. We enter our name. We say that our language is PHP. If we attempt to undo that, nothing should happen. It should say you cannot revert this step, which means that if we press ENTER once again, that should be the end of the steps. If we've got this key combination incorrect, then essentially the prompt cycle will never

that should be the end of the steps. If we've got this key combination incorrect, then essentially the prompt cycle will never end and this test will fail anyway. Just to show you that that's the case, imagine that I remove this ENTER at the bottom and I rerun this test. Note that it's in a constant loop now. We are stuck inside the program until php runs out of memory. So that's a great way to ensure that all of this step logic actually works correctly. If the test runs out of memory, it means that you've got your key presses incorrect. But just to be sure, how about we use that little prompt ASSERT OUTPUT CONTAINS to say

If the test runs out of memory, it means that you've got your key presses incorrect. But just to be sure, how about we use that little prompt ASSERT OUTPUT CONTAINS to say this cannot be reverted, which obviously will be shown under the prompt when they click CONTROL U. Run the test and it passes. Not only can we revert a step, but we're able to run custom logic when we revert a step. We'll paste in our template test again. And perhaps this time, rather than saying that we can't revert this step, we'll say we can revert it, but we should perform some additional logic at the same time.

And perhaps this time, rather than saying that we can't revert this step, we'll say we can revert it, but we should perform some additional logic at the same time. So perhaps for now we'll just show an information panel and we'll say Hello World!! And then we'll use an exclamation mark so it's nice and clear. We need to obviously go back once we've got to this state, which will be here. So KEY CONTROL U. Obviously that will put me back at what is your language, so then I'll have to press KEY ENTER again, and then finally I can confirm with KEY ENTER as well. So I would expect these responses to be the same, although I don't actually need to check any responses in this test.

So I would expect these responses to be the same, although I don't actually need to check any responses in this test. It's redundant to try and check them. So we'll remove those for now. And instead we'll just say PROMPT ASSERT OUTPUT CONTAINS Hello World! Like so. Let's run the test. And once again, we're passing. For checking that we pass all available responses to each step, we'll drop in our template. And how about in Are You Sure?

For checking that we pass all available responses to each step, we'll drop in our template. And how about in Are You Sure?? We update this to actually use dynamic templates. So we'll accept the responses here. And we'll say Are You Sure?? Your name is responses[0], and your language is responses[1]. And that will allow us just to confirm that we are passing the strings through to responses correctly. So if I enter Luke and then I enter PHP, I can actually check that we see a certain question in the output.

So if I enter Luke and then I enter php, I can actually check that we see a certain question in the output. PROMPT ASSERT OUTPUT CONTAINS. And how about we just copy and paste this string here, and then I'll hard code the actual values. So Are You Sure? Your name is Luke, and your language is php. Let's run. And we're passing. Now we want to check that we can actually key a certain step by a given string.

And we're passing. Now we want to check that we can actually key a certain step by a given string. Once again, we're going to drop in our template prompt. And how about we call this one name. So key is name. And we'll call this one language. Key is language. And I'll tell you what, we could actually copy this exact same step check that we used for the previous test, and we'll replace this confirmation with it here. There we go.

for the previous test, and we'll replace this confirmation with it here. There we go. So now instead of accessing this with responses[0], we should be able to access responses['name'] and responses['language'] like so. And we can check the same PROMPT_ASSERT_OUTPUT_CONTAINS at the bottom of our test, run it, and boom, everything works. One test that I've realized I've skipped is the test to check that when you perform a revert closure, you can accept the array of responses in that closure as well. So we could copy and paste this test that we wrote about passing all available responses to each step.

So we could copy and paste this test that we wrote about passing all available responses to each step. But of course, instead, we're going to say it passes all available responses to each step revert closure. And further down, how about we define a revert closure? Here we go. We'll say revert is equal to a closure that accepts responses. And why don't we say in this case, information you selected, and then we'll show responses. And I'm going to key this. So we'll say responses language like so.

And I'm going to key this. So we'll say responses language like so. That should be all right for what we're looking for. And then I'll add a key, which is going to be language. Drop that onto a separate line. I'm going to simplify this final line by copying and pasting the more simple are you sure confirmation seeing as that's not actually what we're testing for in this particular test. Keep your tests simple and straightforward wherever possible. And everything else should be good as far as this is concerned. Obviously we'll need to revert the step.

And everything else should be good as far as this is concerned. Obviously we'll need to revert the step. So that would be here. And then we'll say key enter again so that we make sure we come out of the other side of the steps. And then at the bottom here, I want to say you selected php. So we'll update assertOutputContains. You selected php. There we go. Run the test.

There we go. Run the test. And we're passing. We can be sure that we're good to go on that one. So our final test is that we don't allow reverting normal prompts. Obviously, if you're using prompts as is without steps, you shouldn't be able to revert to set this up. I'm going to make use of our standard test template, but we'll make a few changes for one. I'm not going to confirm at the end of the steps.

one. I'm not going to confirm at the end of the steps. So we don't need this final enter. However, after the steps have executed, I'll confirm the outside of the step builder. We'll say confirm equals confirm. Are you sure? And obviously, I'd expect confirm to be true at the end of the test, but after we actually enter that prompt, before we confirm, I'm going to hit key Control U and then key Enter. So I'd also expect that there was an output prompt, assertOutputContains, this cannot be reverted.

So I'd also expect that there was an output prompt, assert output contains, this cannot be reverted. All right, let's run it. Level asserting that the output contains this cannot be reverted, and you can see actually reverting was allowed. How was reverting allowed? Let's go to the stepBuilder. We set revert using, but we never reset it to null after our steps are complete. So I think under here, we'd have to say promptRevert using null again, and now our test passes.

So I think under here, we'd have to say promptRevert using $is equal to null again, and now our test passes. Actually considering that, we probably want to give this an initial value. Let's set it to null by default, and then let's rerun all of the tests inside our file to make sure that nothing's broken. Brilliant. So we now have eight tests that run in a few milliseconds to inform us if any change we make breaks the functionality of steps. And with that power, we're actually able to perform some cleanups and refactors so that the code that we've written is presentable in a pull request.

And with that power, we're actually able to perform some cleanups and refactors so that the code that we've written is presentable in a pull request.