Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
okay I think we're going to get going here thank you for staying and coming to a five o'clock session especially one that's going to be code heavy so this is a talk by me and kat bailey but you'll notice capability is not here so which you
couldn't make it so it is just me I'm marks on a bomb I'm a performance engineer a Takuya although my job is mostly performance I also do a lot of work just to object-oriented programming in general in Drupal 8 and I helped get the get phpunit
integer play so I'm passionate about unit testing and unit testability so first what is a unit test it verifies the behavior of a unit of code in isolation independent of application context they're fast but fast tests aren't always unit tests
unfortunately they do not replace integration and acceptance tests as slow as our test suite is now we will never get it into like 10 seconds by making them all unit tests because we can't convert them all we still need acceptance tests and integration
so why unit test mostly code quality when you force them to do unit tested you you're you're forcing that code to be context independent you're saying I can run this code and I can verify its behavior outside of the context that it's run in
a good unit test also serves as documentation there are other communities that are not not necessarily in the PHP or especially Drupal world where the tests are actually their best documentation and often times they're better than written documentation
because you can see exactly how things used their refactoring it's very very painful to refactor without unit tests anyone who has worked on Drupal 8 and had a random test failure for some web test and had to debug that you probably felt that pain the
feedback loop on that is very very slow and it may break something that is complete unrelated to what you're doing the feedback is also extremely valuable when you're coding and you have unit tests you're constantly running them and you know instantly
when you break something and it's a constant feedback loop with the tests now we talked a lot about testable code I'm sure if you've been involved in Drupal 8 especially with the if you familiar with the service container and at the general dependency
injection trend and Drupal 8 you've probably heard about testable code but just to define it I like this quote from the growing object-oriented software guided by test book for class to be easy to unit test the class mess has explicit dependencies that
can be easily substituted and clear responsibilities that can be easily invoked and verified so to sort of illustrate that point and here's an example of some code from t 7 this code adds a role to a user I believe it is triggered with the action that
does that it is an action right it's just really confusing because the word action never appears anywhere here but so if you look at this code if we look at the dependencies all right we see the we see the parameters right so you have an explicit dependency
on accounts operation and roll you have operation because it does multiple things and then you have implicit dependencies you have DB query user load multiple and user save so those right there and now if you're in a unit test and you were trying to run
this you would need all of those functions available so you'd include the files that have those but those function calls those functions call other functions and so now you need all the files that those are in and the files that are those are in and on
and on this is the level which I stopped doing this by hand yes so the same code from d8 so a drool you or a droll user object a little bit strangely named but it is an action plugin it takes the account and then it has the role the role actually got injected
be its constructor because it's a plug-in a little weird but to explicit dependencies and here all we have is a call to has role and then if it doesn't have the role it calls a droll and save on that user object so no function calls now if we look
at the test for this this has actually existing core you start that out by creating an account mock and in this example it's using mock builder sometimes you need that when you're creating a mock from a test or from a class instead of an interface
so that later and then you set up an expectation you're saying that the method add role will never be called and then you set up an expectation that the has roll the has roll method will be called with this value and it will return true and so that's
basically saying and then if you notice the test is called test execute at existing roll it's saying I'm going to test the situation where the user already has this role I'm going to step the hazard roll method so that it returns true and so that
i'm going to verify that a droll never gets called and then you basically set up that object and then you just do execute you'll notice there's no assertion at the end who hears written a simple test for okay dhp unit okay so especially the people
who done simple test you're probably used to just always using like this assert equal assert something the assertion here is in the expectation this is an example of using a true mock and when you say like on the second one that's more of a stub because
it's saying this any but when you say this never that means if the method is called once the test fails it has the test only passes when it gets called zero times so i would say in this example we have clear responsibilities and they're very easy to
invoke and verify and they're explicit and it was very easy to substitute them so i mentioned briefly mocks and stubs to clarify these these terms there too two types of attest doubles that's a sort of a recent dish term but it's a it's an
[ ... ]
Nota: se han omitido las otras 2.892 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.