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

End-to-End Testing Setup0:00

All right, today I'm working on Laravel Mix again. I'm trying to wrap up the official 1.0 release, where a lot of refactoring has taken place, a lot of retooling, a lot of bug fixes, so just about ready. But one thing I've set up and that I'm working on right now is just general end-to-end tests. You can call them system tests, you can call them acceptance testing, whatever you want. But this is... well, let me show you. When it comes to my tests, you have everything like, well, I have a File class. So this does everything you would expect a File to do, like it tells you its size, you can detect whether the File exists, you can delete it, you can get the name, you can do lots of stuff. So, of course, I have individual tests for each of those Files, and it takes the shape of something like this.

Acceptance Test Example1:11

but you also want to have some larger end-to-end tests that actually make sure that what goes through the tube comes out the other end, right? So I have a acceptance test here, and you can see, well first, let's just take a look at one. It compiles JavaScript. Very basic. So given the User has this webpack.mix.js configuration file, well, when I compile it down with Webpack, then I expect a file to be created in the public/js directory. And then further, I want to read that mix manifest. If you're familiar with mix at all, you'll know that this gets created. Well, I want to read that file and make sure it's equal specifically to this. Okay, so let's just go over it very quickly. So, well first, I'm using a test framework called Aeha. This works with Node. It's really good. Very clean, simple. I love it.

Triggering Webpack Programmatically2:37

So after every test, we can delete the public directory entirely, so we can start from scratch. And then before every test, we'll just whip that up again. Now, if we switch back, what does it mean to compile? This is just simple extraction here. Here's the actual logic for how you can, using Node, programmatically trigger Webpack. So you call, at the very top, we pull in Webpack, and then we call Webpack, we give it our configuration file, and I build up with, you may not know this, but when you're using Mix, after you use the API, like mix.js, ultimately, this gets triggered. So we have a WebpackConfig class, and if you scroll down, we call build, and yeah, that just builds up every section of that Webpack configuration file. So once that's created, I pass it to Webpack, and then once Webpack has finished compiling, I trigger our callback here, and then I enter the test. Okay, so now, for any of these here,

So once that's created, I pass it to Webpack, and then once Webpack has finished compiling, I trigger our callback here, and then I enter the test. Okay, so now, for any of these here, like this one, compile down Webpack, and when you're done, how do I assert that the output is what I expect? And often, that's just making sure the file exists, and making sure the manifest exists. So we can see that we have some for compiling JavaScript, compiling JavaScript and Sass. So in that case, it should create a CSS file, and the manifest should reflect that. We have another one for compiling Sass, but then you don't do JavaScript. So in those situations, with Webpack, it gets a little tricky, and I have to take care of that. So let's make sure that works, and then finally, we can compile JavaScript and Sass,

So in those situations, with Webpack, it gets a little tricky, and I have to take care of that. So let's make sure that works, and then finally, we can compile JavaScript and Sass, but we can also add versioning, unique versioning, to each of the files. So in that case, the real test I'm doing here is making sure that the mix.manifest file does have the unique hashes attached to the file names. All right, so that means I can now test this by saying php artisan test features mix, and we get green. So this is, like, these are in many ways the most important test to me. The unit tests that I have, those are great, and they help my workflow, but when it comes to sleeping at night, these are the sorts of tests that make me feel most comfortable. And further, when a PR comes in on GitHub, if it breaks any of the tests within this file or in this directory,

Writing a Copy Test4:41

these are the sorts of tests that make me feel most comfortable. And further, when a PR comes in on GitHub, if it breaks any of the tests within this file or in this directory, I know almost right away I can close it or ask for additional commits to fix things, because this is, like, this is my metric for how I know does mix work the way I expect. So why don't we flesh this out a bit more? So let's go ahead and just write another one together. Now, how about, I want to test that you can copy a file. So let's just leave that blank for a minute. We can do things, like if I steal this, compile this down, but then once Webpack has finished with that, I want to copy the output. So I could always say copy, and we have to give it the full path, fakeapp/public/js,

compile this down, but then once Webpack has finished with that, I want to copy the output. So I could always say copy, and we have to give it the full path, fakeapp/public/js/app.js, and we're going to copy that to somewhere else. So how about somewhere and, yeah, leave it like that. Okay, we want to make sure that this works the way we expect. So, we're going to compile things down, and then, well, let's just leave this blank for now and make sure that we do compile it as we expect. Now, a quick little AVA tip. You can add the .only flag or extension or modifier, whatever it's called, to a test, and that will ensure that only that single test is triggered. And we get green. That doesn't mean anything.

Now, a quick little AVA tip. You can add the .only flag or extension or modifier, whatever it's called, to a test, and that will ensure that only that single test is triggered. And we get green. That doesn't mean anything. It just means we didn't get an error. So my assertion will be, if I can find something to steal here, let's steal that. Okay, my assertion is going to be that this file exists. So public somewhere, app.js. That file needs to exist. So we're going to compile it down, and we get green. So it works. Now, another thing, though, as part of this, when you copy a file, I want to make sure that it also is reflected within the manifest file. So take a look. In this case, I've already written the code to make it work, but just to show you. If we run it, yeah, you're going to see that when you copy a file to a new location,

I've already written the code to make it work, but just to show you. If we run it, yeah, you're going to see that when you copy a file to a new location, we also throw it into the mix manifest file so that you can read that if you need to. And then further, if you're not aware of why you would ever use that mix manifest, it's related to versioning. So if you version your assets using the Laravel or whatever tool you want, you can read in this file, and you can say, well, I want this file, but give me the versioned representation of that. And then Laravel will just give you that unique string here. And then whenever the file changes, this hash will update because it's just doing an MD5, and then you always have a good cache busting in place. Okay, but anyways, let's

this hash will update because it's just doing an MD5, and then you always have a good cache busting in place. Okay, but anyways, let's remove that, bring it back, and we're just going to cheat a little bit because that's ultimately what I want our manifest to look like. So we're going to take this, and let's see, we have app.js, and then the same for somewhere, app.js. Okay, let's run the test again and see if we're still getting green. We are. I can get rid of only,

Adding Concatenation Test7:41

somewhere, app.js. Okay, let's run the test again and see if we're still getting green. We are. I can get rid of only, run it again, and everything's passing. So now let's just say it compiles JavaScript and copies the output to a new location. Why don't we do one more related to concatenation? So I'm going to update my stub here. I'm going to have another .js, another stub, and let's see, we're going to steal all of that. Whoops.

and let's see, we're going to steal all of that. Whoops. And this test will be, it compiles JavaScript and then combines the bundled files. All right, so we're going to do this. Given that I have two different bundles here, bundleAnother.js, and then what I'm going to do is combine, or we can use .scripts, which is an alias for that, and we will take, what do we need here?

and then what I'm going to do is combine, or we can use .scripts, which is an alias for that, and we will take, what do we need here? test fakeApp public/js/app.js, and then another one. Take those and move those to fakeApp public/js/all.js. Yeah, and that's going to be our script. So bundle this down, bundle that down, and then take those two compiled files and join them into one. And if everything went according to plan,

So bundle this down, bundle that down, and then take those two compiled files and join them into one. And if everything went according to plan, well, then I expect js all.js to exist, and we could even take it further if we want, where we have a pre-compiled script that's exactly the way we want, and then we make sure that they actually look identical to one another. So that's definitely an option, too. Anyways, let's go ahead and run this, and it passes. So we're not necessarily doing TDD here, and that's okay. Do TDD where it makes most sense to you, and then other areas where it just, you need to spike it out a little more, you can come back and write the test, or what even some people do is they spike it out,

Do TDD where it makes most sense to you, and then other areas where it just, you need to spike it out a little more, you can come back and write the test, or what even some people do is they spike it out, they figure out finally how they want, and then they comment everything out or do a git checkout so they can start from scratch doing TDD. It doesn't matter. I really don't care either way. Whatever works for you. So anyways, finally, I do expect app.js to exist. I expect another .js to exist, but then just like copying, we will expect this file to exist. So I think that one should be all.js. Right? Is that right? Let's give it a shot. Let's trigger only that test. Oh, and it fails.

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