تماشای این درس نیاز به اشتراک حرفه‌ای دارد.

VimTest commands overview0:38

If we come down to php, we'll see we have all these options, including some I've never even heard of. If we keep scrolling down, we'll see that VimTest offers us several different commands, and testNearest is by far my favorite. When we run this command, it'll run the test that's nearest to our cursor. Otherwise, it'll run the last nearest test. We can also run the entire test file on its own, and of course the test suite. We can also run the last test from anywhere we are, and we can jump to the test that we just ran if we're somewhere else in our codebase. VimTest also supports a variety of different strategies.

Installing and configuring VimTest1:07

and we can jump to the test that we just ran if we're somewhere else in our codebase. VimTest also supports a variety of different strategies. So by default, it'll open up near Vim's terminal, but you'll see there's all these different strategies, so there's one for float term, to run our tests in a variety of different ways. So let's go ahead and install it. We'll jump back into our plugins.lua file, and let's jump back down to the bottom again to after our last plugin, and I'm going to paste in the configuration for VimTest. This one's pretty lightweight, but I do have a few options that I like to set for it,

and I'm going to paste in the configuration for VimTest. This one's pretty lightweight, but I do have a few options that I like to set for it, so I've set up a module. So let's go ahead and create that at nvim/lua/user/plugins/vimtest.lua. So to start with, I'm just going to set up these mappings. So let's go ahead and save this, and we'll run Packer Sync. And now we can jump over into our Laravel project, and let's open up our UserControllerTest that we created earlier. Let's go ahead and use our test snippet to create a snippet for test. It does something, and inside here, we'll say this->assertTrue(true).

Running nearest and suite2:07

Let's go ahead and use our test snippet to create a snippet for test. It does something, and inside here, we'll say assert(true, true). Let's create another one, so let's say test it fails, and this one will be assert(true, false). All right, so with my cursor inside this test, if I say php artisan test, you'll see that it runs just this test. Now this has opened this in NeoVim's default terminal, which is pretty good, and if I press the Q key here, it'll jump us back to where we were. If we come over to the failing test and run php artisan test to run that test, then we'll see the output from that.

If we come over to the failing test and run tn to run that test, then we'll see the output from that. I can, of course, say leader tf to do the entire file that we're in, and we have one failure in there, and if I do leader ts, then we run the entire test suite and see the results. Now vimtest is pretty clever. If we're using php, it will try to determine the appropriate test runner to use, so it'll check for things like paratest, it'll look for sale, and it'll look for things like pest as well. But I'm not a huge fan of it opening up in a terminal window like that,

Custom floating terminal strategy3:18

and it'll look for things like pest as well. But I'm not a huge fan of it opening up in a terminal window like that, so let's jump back over to our config, and I'm going to paste in a custom strategy. So you might have noticed that vimtest had a built-in strategy for floater, but I like to change the behavior of it a little bit. Now vimtest uses variables with a hash in the name, which is common in VimScript, and as far as I know, there's no easy way to set those using Lua. So at the moment, I've got an entire VimScript configuration for that

that this is the strategy I want to use for everything. For the strategy itself, I'm calling float term kill, but I'm running that silently. So this just makes sure that if I have any float terms running, it will kill those, and if there aren't any running, it won't show any errors. And then I execute float term new with the command, so this is the test command that it'll run, and I pipe this through less with the -X flag. And the cool thing about this is less is a pager on Unix,

Paging output with less4:29

and I pipe this through less with the dash capital -X flag. And the cool thing about this is less is a pager on Unix, so you can pipe a long string of text to this, and it'll allow you to scroll through it really easily. So what this means is if we run a test that has a lot of output, it'll keep us scrolled to the top of the output, because normally I want to see the test failure rather than the very bottom of the stack trace. So let's go ahead and save this, and we'll jump back over to our Laravel repo,

So let's go ahead and save this, and we'll jump back over to our Laravel repo, and let's quit out of them and open it up again. And now if we run our test nearest, you'll see it's opened up in a floating terminal here. It's also piped this into the less pager, and I can kind of scroll down here, but you'll see that by default it placed us at the top of the test, which I find really nice. In this particular example, we don't have a really long stack trace,

Run Current TestRun Current Test CaseRun a Full SuiteOutput Customization

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟