Drupal Test Traits - Learn by example

This talk focuses on the functionality and benefits of Drupal Test Traits (DTT) within the Drupal testing ecosystem. The speaker, who has extensive experience with Drupal since 2001, explains how DTT allows developers to run tests using an existing site's database instead of reinstalling a fresh database each time, saving significant time and resources. They detail the advantages of utilizing PHPUnit with DTT for testing, highlighting features such as headless browser testing, email collection for assertions, and performance testing. Additionally, the speaker shares success stories demonstrating speed improvements and maintenance efficiencies achieved by teams that have transitioned from traditional testing methods to DTT. The session concludes with insights on integrating DTT into existing workflows and its compatibility with different testing frameworks.

All right, let's begin. Welcome to Drupal Con Chicago. Congrats on uh making it so early in the morning. You guys are the high achievers. Um I'm also an early morning person, so this was no problem for me. I've been presenting at Drupal Con since the very first one. Um, I've never had cabaret seating before. I feel like I should do standup comedy if this uh has time

at the end. A little bit about me. Uh, I consult uh with Tag One. Um, a great agency. Look us up if you guys have any needs. Um, I also consult independently. Look me up if you have any needs. Uh, for a solo person. Um, like I said, I've been around for a very long time. Um, I've been working on Drupal since 2001. Um, so that was

25 years ago. It was, um, the very first year I started working on it. I was pretty much the first American to work on Drupal. Um, I've had a lot of different pieces that I've introduced and handed off. Um, I'm still the Drush and Devel maintainer. Um, and some other things I've worked on there, groups.grupal.org, um, the conduct policy, um, and Drupal test traits, uh, the DDEV

contrib um, and D7CX, uh, things that we can barely remember what they stand for now, um, in the security team. So, today we're talking about Drupal test traits. Um, here's what you'll hear more about. Um just want to kind of introduce what Drupal test traits are for. Um the Drupal testing system uh is really like a worldclass system. Um in my opinion uh it wasn't always so.

Um it started off as something built on another open source project called simple test. I introduced that into Drupal uh a long time ago. that was not that good. Um, but then again, it was a long time ago and there weren't many things. PHPUnit was a thing at the time and we evaluated simple tests versus PHPUnit um and picked the one that didn't survive uh and we

did eventually for Drupal 8 switch over to PHPUnit and it's been pretty great since then. Um the thing that Drupal test traits is special about is that um the Drupal testing system on its own reinstalls the database from scratch for every test. And that takes time. And so Drupal test traits cuts that out completely and says you bring your own database to the picture and then we'll

run the tests with all the same capabilities, the same headless browser that can fill out forms and click things and do assertions. Um, so all of that that you're familiar with if you've done written tests for Drupal Core or Drupal contrib, you do all the same things. Uh, but you don't have to reinstall the database every time. Um, so the cool thing about not having to reinstall

the database all the time is that you actually bring in your site's database. So, um, you know, I'll speak from the perspective of a consultant. Uh, your client has a site in a database that's been running for one year or 20 years, however long it is. Um, and so, um, you just bring that into an instance and start running tests on it. And your tests can do

things like click on the actual navigation that has been configured for the site and has been running well for years and make sure that's still working well. Um, and rely on the roles that are already in the site in order to test if access control is working correctly and so forth. So you don't have to set up the world like uh regular Drupal testing does. Um, it's

already set up for you and the thing you're testing is the actual thing that the client cares about. like it makes no sense to to build a Scratch site and test that when um what you have to make sure is that the actual site is working uh with all of its configuration and content and so forth. And uh just to contrast DT with one other system that's

popular for doing this kind of thing um you might have heard a system called Bhat um which is a very cool system uh for doing testing um but it really has a different goal than DTT tests and you know I quote here from the readney of um the Bhat project and they're very clear about what their goals is um which is great. Uh it's about facilitating a

communication between the product people who are defining what is to be built and the developers who are doing the building or the agent developers who are doing the building now. Um and uh that's useful but that's typically not what the projects need on my project on my teams. They really want more traditional unit testing. It's not really about the conversation between the product person and the developer.

A lot of times it's actually the developer who is leading the the um feature definition uh along with an approver type person from the product. Okay. So um here's how you get started on Drupal test traits. Um, it's really a composer package. Uh, and so whitesman druprupal- test-traits is what you bring into your project. Um, and one more dependency you're going to need uh the same things

that Drupal core depends on when it does testing. So that's what the Drupalcore dev is about in that composer require line. Um, and there's one important environment variable that you have to set, and that is the DTT base URL. And that tells the testing system how it can reach your site when it needs to load up pages and fill out forms and Um, I'm hoping that these

code slides are large enough to see in the back of the room. I got a thumbs up back there. Great. Shout out to all the cool kids in the back. Um so here's how you run Drupal test traits tests. Um you'll see that it's run with PHPUnit. So you know this is a key idea is that this is just PHP unit the tests we're talking about. It's

not like a different testing system um like simple test was or pest is in the PHP world. This is these are PHP unit tests. Um, so you're already quite familiar with how to build them and how to run them and so forth. Um, so we use some of the flags uh that um the PHPUnit command line program recognizes. Here we're passing d-configuration. That's optional. Um, but what

you get if you um put in this file uh phpunit-debug xml which is brand new in the project. So, if you already have a checkout, you might not see that one. Um, but uh you will get uh some very cool browser output. I'll show this later. Um, but as the test is clicking around and looking at pages and filling out forms and making assertions, it will save

each one of those pages to your browser output directory. You might be familiar um with how Drupal core testing does this and contrib testing does this. It's the same stuff we're using here. That's what the d- configuration does. The bootstrap um is basically makes this test this testing faster than Drupal core um by discovering classes faster. And um just to show here that you can use other

command line um options here. We're using d- filter to run just one test. You can use d-group. You can not pass more options. You can pass arguments. All the same stuff that PHPUnit usually accepts, it will accept for these tests. Um, and below that command line, you'll see what the output looks like. This should be familiar, too, if you've ever run PHP unit tests. It's the same

stuff. Um, you will see Sebastian Berman puts his name on every single execution of his program. I would never do such a thing, but he and uh then you see the output. Uh there's a period for each test that ran and uh one of one failed, one of one passed. Um and uh here's the output files that I was talking about. HTML output was generated. And there's

even handy links. Um, if you have a modern terminal, you can click on URLs that are show up in the terminal and you'll your site will serve these HTML pages and you can quickly see why your test failed. You'll you'll see the access denied that your form got and you didn't think it should or some form field wasn't there and that's why your test failed. Um, so

this this debug output is very helpful. Um, and at the end you'll see the usual results. So, just to show you if you do click on one of those links, um here's what the browser output looks like. Uh this was the page number 19. Sorry, it's quite small. In the upper left, um you have previous and next links, so you can actually see what the browser recorded

as it was going through your tests. Um, and you see a little bit of code and a URL about what note here was node 25. Um, and this was a simple node with um the title llama and some body text um that was just randomly generated that the the code that the the test So we've learned how to install DTT. We've learned how to run its tests.

So um now we are going to learn a lot about authoring tests with Drupal test traits. So um here's like an introductory test. looking at the first line here we have the test name simple example test. Uh the important part here is that uh your class should end with te like this. um PHP unit requires that by default uh in order for your test to be discovered.

We're extending a class called existing site base. So this is a class that ships and um it basically includes other traits in it it's a class that includes traits that are the Drupal test traits and it's a convenience class. you actually don't have to use it. Um, if you already have a base class or it makes sense for you to have a base class for your project,

you can have your own base class and you can just include the traits directly that existing site base already includes for you. Okay, moving on. There's a one test method. Test blog content type. And um this thing is going to do some standard tough stuff that tests often do. In the beginning, it's going to create a user. It's going to load up an existing vocabulary and it's

going to create a term in that vocabulary. it's going to create a node uh that has that term that's using that term. Okay, so this is like standard setup stuff. The important notes here are that you can use um these convenience methods like create user, create term um and this is provided by the Drupal testing framework. Okay, so there's there's rich functionality there. Um it's It is

wrapped by Drupal test trait like uh create user or something that Drupal core provides. We wrap it just to note which nodes and users and terms you're creating so that we can delete them at the end of the test run. So remember that we are using an existing database here. Um, and so it's nice if we don't just keep creating nodes and creating nodes and users and

pollute that database. Um, so you'd never run these DTT tests on your production database. This is something you want to do in CI or on your local desktop. Um, but in any case, even in those environments, it's nice to do cleanup when we can. And so um we log if you use these helpers we log what you create and during tear down we automatically do the deletion

for Uh so then going down to the middle section um we do a Drupal get which is the way you load up a page. Um so here we're just asking the actual node entity object give us your URL and Drupal get will then go there. um and it's using a headless browser um that uh I think the mink browser and it's going ahead and it's um making

that request. We do an assert that the request succeeded by uh asserting the status code. 200 is a success. Um we can also do things like uh log in um as anyone that you want. So here we made an author with the right permissions and we are going to go ahead and go to the edit form URL uh and make sure that we got a 200. Again,

if for some reason the author was not allowed to see this, the test would fail and you'd have to go debug what's going on with your site. Um so as you can see, we can use the Drupal entity system uh at will. um vocabulary load up there. We can use any API we want from Drupal. So uh you know in Bhat you might be used to making

step definitions and having like or the Drupal extension project um in other times where you'd have to like wrap Drupal and things. No, we use Drupal directly in DTT which is a lot faster um and uses knowledge you already have. Okay. So, uh that was a headless browser. Um doing the Drupal gets. Here we have something different. Um we have uh extending existing site Selenium 2 driver

test space. Um sorry for the long name, but it's a cool class. And what it does is it uses an actual browser. So, um, this will use often the Chrome browser, um, to go ahead and do your Drupal gets and Drupal posts and so forth, fill out forms, and, um, in addition, it can do things like execute the JavaScript that's on the page. So, this test, um,

is going to, uh, node add article in the in the third line there, and it's actually filling out the article form. So fill field fill field set the value um and key down. So what we're happening here is we're actually getting we're testing the autocomplete. Wow, the mic is working better if I get close to it. Sorry about that. Um so we're filling out the autocomplete and

making sure that it works. That's something you can't do in a headless browser because there's no JavaScript that's executing on the page. So if you are tasked with doing um testing of more client side functionality, DTT is a great partner for you and you would extend this test class in order to do If you're doing sort of more regular testing, I would say don't use one of

these tests because uh the Chrome testing is a little more complicated and a little slower. Okay. Okay. So, um here we are. Uh we have a series of uh success stories that I collected in Slack uh from people who are using DTT. And here's one of them from Dan Flanigan who's in the room. Thanks for this, Dan. Um Dan moved a module that had lots of configuration

from a functional test to a Drupal test traits test. And um there were two main advantages that he told me about. Um this test had a lot of configuration. This module that he was testing had a lot of configuration. And so what he was doing um before he used DTT was he had it configured in his site and the client was happily using it and he had

a copy of the configuration that the test needed in its module directory um so that when the module got installed in the test it would start behaving exactly like the module does in prod. Well, that was a lot of maintenance to keep both sets of configuration in sync and it's subject to neglect and out of sync problems. And so when you are testing your actual site, there's

no out of sync possibility. Um so that's quite a nice uh maintenance benefit uh and sort of reliability benefit. The second one is the speed benefit. um he didn't have to reinstall his whole database every time once he adopted DTT um and didn't have to go through that config import of getting all the config in when you enable your module and so forth. So um his test

went from 29 minutes to 3 minutes. Um so you get some real nice speed benefits from adopting DTT depending on where you're coming from. Back to the code. Here we have sort of a more advanced um Drupal test traits test. So you get a feel of other things that can be done. Um this one comes from or uses code that phase 2 developed. Thank you for that

phase 2. Okay. So um we are again extending existing site base here. Um, and we're using some traits that come with Drupal test traits, namely the mail collector and the QRunner. And in setup, we're starting mail collection, and we're clearing out the que. So Q's here are regular Drupal cues. Um, and mail collection is email. Okay. So what the mail collector does in Drupal test rates and

again it's just wrapping some code that comes with Drupal core u it's intercepting things that the Drupal mail system sends and saving them in an array so that you can perform assertions on mail that was sent during your test. Uh so we're not actually sending the mail. That would be bad. and instead we're collecting it and we can assert on things like the subject is correct and

the messages correct and the re recipients are right and uh so forth. So this bit of code that we're testing um this comes from a project I worked on mass.gov which is the main website from the state of Massachusetts. the Massachusetts has a feature where authors can schedule a page for unpublishing. Uh so if they know a certain you know campaign website supposed to come down 3

weeks from now you can go into the node and you schedule it for um Um the scheduled actions module uh provides that. It's a really cool module. Um so we wanted to test if that was working and that the unpublish reminder functionality that we built is working also. So, um, basically, uh, 3 days before the scheduled unpublished date, I think the author gets an email reminding them

that this is scheduled for unpublishing and they can they can change the date or remove it or whatever if they need to. So, um, the the test method here, test unpublish reminder, is creating a node and setting the field unpublish on to a certain date in the future. And then we are running the Q worker and that is the thing that actually sends the mail. So when

you save the node you you save it to a queue and then you process the queue and that sends the And then down here, this assert mail collection basically we're finding all the email that this module sent mass unpublish. Um, and we are looking for the the recipient that we sent it to and we're asserting that that person actually got one email. Um, and the header there's

a there's a CC in the email because you're supposed to CC some other address. uh and you can go ahead. This test asserts that the content of the email is correct also. So Q running and mail sending are also possible with Drupal test traits. Um and you know if Drupal test traits doesn't have the thing you're testing, it's relatively simple to build new traits and to assert

those things too. All right. Uh here's another trait that comes with Drupal test traits. This one is called the entity crawler trait. You see it in the second line here. So what uh previous next um an awesome Drupal agency contributed here is that uh they wanted to make their tests even faster than DTT's already fast tests um by getting HTTP out of the picture. There's no real

reason if we're just testing that a node renders correctly, we don't need all the Chrome that the rest of the page gives you. So um the entity crawler trait renders a node for you directly and you can assert that it has the right fields and values and layout and so forth and no HTTP's involved. No theme is in no theme chrome you know menu and chrome header

footer none of that stuff. So these are super fast. You know, taking a look at this. Um, the first thing that these tests do is they get the rendered entity crawler and this thing gets passed an entity and a display mode. So in this case, we are rendering that node that we just created in the full display and attaching that to the crawler. The crawler that's getting

returned here is of type uh symfony crawler. That's the project. Um it's basically a DOM representation of some HTML. Uh and then you make assertions using the crawler here. So assertain that um the H2 with a node title class its text um is my blog. Okay. So, um the title is my blog. We want to make sure that the titles are rendering and they're correct. That's what

that assertion is doing. Um and the next part, you can get the content out of the node node content um node in the DOM and you can then get the body and make an assertion on the body text. Okay. So um it's a different approach uh if you want to speed up your sort of entity assertions even more. And just at the end here, this example wants

to say that if you're tasked with making sure that the entity body is um building up the right cache tags, for example, you can assert on other things in the build array besides the actual output. Uh so this is asserting that build pound cache in tags here in the bottom right um contains that one tag with filter format. So you didn't screw up something about filters uh

and cache tag collection in your entity rendering. Okay. So another quote from Lendude here. uh Lendude uh has a GraphQL site, a site that serves GraphQL, and he found DTT to be an an excellent fit for that use case. Um and uh that's because DTT is so close to the Drupal APIs that uh you can send GraphQL requests and look at their responses uh without much trouble.

So, um, definitely want to encourage you to look at DT for, you know, odd use cases like this or unusual use cases. Here's one more example test. Um, this one comes from the NSW government in Australia. Uh, again from previous next. So they have a test class which um is in their repo now. It's going to be coming into the the Drupal testates repo soon test traits

repo soon. uh they have overridden the the um the Drupal get function or wrapped the Drupal get function with an assertion that makes sure that the dynamic page cache is working for this site in this page So it's really easy to break dynamic page cache by doing something in contrib or in your custom code and that has some pretty serious repercussions for the performance of your site.

Um and so this is with just a few lines you can take your whole test suite and make sure that the cache responses are coming back correct. So, um, what we've done here is is made sure the page cache is working on all our requests except for requests that match this ignore pattern. Um, so you just have a a an array of patterns where you know that

dynamic page cache isn't supposed to work and you don't care. Um so here we have like admin pages and edit the edit page and the logout page where um we just don't need dynamic page cache working um and otherwise it's going to work. Uh previous next shared an example where the admin toolbar um made a new release. This is a super popular module. Um, and they broke

dynamic page cache for any site that updated to their latest release. Um, and the CI for previous Nex caught that and quickly they submitted a fix for admin toolbar before, you know, it went wide into the ecosystem. And so that's like an example of this thing really helping out the Drupal community. So, here's uh one more test um that might get you an idea of how you

might use DTT. Um here uh we have a smoke test that uh someone contributed to us that is going through all of the content types on the site and iterating them. That's what this for each loop is about here. Um, and it's just loading up the most recent node from each of those types and making assertions that uh we got the right status code, we didn't get

access denied, we didn't get a fatal error. Um, and the title of this this class is the smoke test class. So, this gave the release manager more confidence that something wasn't terribly wrong with the release that they're about to roll out. Um, so I think it makes a lot of sense to have a test like this in your suite. Um, and um, and you're not going to

like roll something out and take the whole site down. Uh, you might have smaller bugs, but you won't have the the big one. Um the city of London contributed um a great feature into Drupal test traits. This is actually in the traits now um where you can do performance tests. So, Drupal Core not that long ago added performance testing um where you can request a page and

do assertions on how many queries this page is supposed to have. Uh how much CSS and scripts this page is supposed to have. And you can set like upper and lower bounds for these things so that you'll know if you have introduced something that adds a thousand new queries or adds you know 2 megabytes of CSS you will know and your test will fail and you can

adjust your expectations or you can fix the problem. So uh here's an example of one of those. Um the top uh it's called the node warm cache test. So the top is warming the cache. It's just making requests. It's making one request to the arts and culture page presumably on a cold cache that has lots of queries and we don't really care. Um but on the warm

cache, we know that we're only supposed to have in this case three queries when we hit that page. And so we assert that assert same that the data get query count in the middle here is the number three. And furthermore, we know exactly what the three queries are. And so we're going to assert the text of those queries here. and then if we keep going down in

the test to the last four lines, we're asserting that the cache get and cache set counts are where they're supposed to be. And then an example of ranges. Um, the last one, we're asserting that the number of script bytes, so like all of the scripts that this page uses is less than an upper bound here. um 183 million bytes. All right. So um basic sort of performance

budgeting, performance bounding, upper lower bounds, all of that stuff is built into Drupal test So here we have um one of my other projects that I think fits in well here. This is the DDEV MTK add-on for DDEV. Um, I mentioned that Drupal test traits assumes that you have the site's database local and sometimes your site's database is huge. And so you have a little bit of

a challenge of like do I really want to get the site's database um every day or every week to my local or in the case of CI you have to bring it down. Um the usual approach for that sort of thing is you take a SQL dump from prod and you you sync that locally and then you import into your local database u my SQL or SQLite.

So the DD MTK project is a way for local developers to more quickly get the site's database. Um the approach here is you use it. It builds on a project by Previous Next called the MySQL toolkit. That's where the MTK comes from. And the MySQL toolkit is a way to um script in your CI system, a way to get that database dump from prod and then load

that database dump into a MySQL instance that's running in Docker and save that as an image and save that image to your Docker container registry. Git GitLab provides one of those. GitHub provides one of those. Docker provides one of those which use whichever one your project likes to use. And now you have since this is scripted in CI you have your sites database saved as a um

image in the registry. And so in DDEV when you run DDEV restart database is not coming from the usual place that DD has your database coming from. It's coming from your you get a DB container from your registry, not something that's built that DDE All right. So, um the speed advantage comes from the fact that all you have to do is pull down that Docker container and

you have a um optionally sanitized version of your site's production database. You do not have to reimpport. So that's the difference is that there's no SQL import anymore. That's done once by the CI system and then all your developers get a already imported database when they do DDEV restart. Okay. So um we have some time for like people to ask questions. Um, we have time for people

to share their success stories or non-success stories about Drupal test rates. So, please I hope you guys uh, you know, have a dialogue here and um, and let's see where it goes right here in the middle. >> So, if you have a site with a very large Bhat test, multiple BAT test suites, is there an easy path to get to this from there? Okay, so the question

was if you have a site that has lots of B hat tests, uh what might be a path for getting to a lot of Drupal test traits tests? Um I'm not aware of a automated way to do that. Um I don't think there is one. the way is to go slowly and to change the ones that you know you think might have the highest value in terms

of speed. Um and along the way the first couple of them are going to be a little bit slow because you're finding your patterns and maybe you are creating some helper methods. You might be making your own base class. Um, and you'll find that after the first couple of tests, they're going to go much faster. Um, some things that were in step definitions can now go into

helper methods that you're going to reuse, you know, right from your setup and so forth. Um, so this process is something that I did go through. The mask.gov gov website that I mentioned earlier had a large B hat test suite and even today years later we didn't convert all of them um because it never quite became a priority to get to the end but we converted all

the ones that mattered and we wanted to and we got the speed benefits from doing so and we got a lot of maintainability benefits from doing so. Certainly when you look at your overall test um runner, the thing that runs in CI, it can run the DTT tests and run the PHP unit tests, run the behead test for a long time. So there there's no problem to

have them running in parallel. Good question. right over here in the back. >> Um, are you aware of anyone using cloud code or another AI for writing tests? >> Uh, right behind you. I guess maybe did you have some experience? Let me repeat the question. I'm supposed to read the question. Um, am I aware of clawed code authoring these sorts of tests? And is was there an

answer behind you? Raised your hand for a second. >> Did a whole bunch of them last night. Okay. I did a whole bunch of them last night, we heard. Um, so great. And it how did it work for you? >> Fantastically. Uh, one of the things you saw earlier is uh that you know we need a custom bootstrapper to discover namespaces and stuff like that. And uh

unlike me who read the wonderful documentation just knew to do that. Claude didn't know all of that. It's like oh bootstrap error. Okay. Well, I think I know what to do. Let me just check the dependencies. And then it whipped it up and did it and uh wrote them Not exactly like I would do them, but pretty acceptably. >> Okay. So, it it sounds like Claude knows

about Drupal test traits um >> like it like it knows about a lot of things. Um and uh and you can, you know, have these authored um by Claude and chat GPT and all the rest. Um okay. So, uh right back here Okay. So, um once you have a test or two in the codebase, Claude will uh follow your patterns and know how to um know how

to author these things. Yeah, that's a good point. So, works even better um once you get started right here in the front. So, have you used a JavaScript testing framework like Cypress or Playright? And how do those compare to what you might do with Google test traits? >> Um, I've used a little bit of those systems, not a lot. I'm not quite the expert in that. Um

I I would say that um since Drupal test traits is so close to Drupal itself, you know, we saw in those tests that you can just call um you can create nodes and load up existing vocabularies and so when you're authoring tests, you often have to do that kind of setup and tear down work and you're you're one step removed, especially, you know, that that stuff is

awkward to do in my experience. And so that would be one benefit of using Drupal test traits is that um if you are a Drupal developer uh this is going to feel a lot more natural and a lot more speedy to do your setup and tear down in um those are certainly wonderful for driving a browser and making assertions and so forth. I think there's probably no

advantage in that respect. Um, you know, but there would be advantage in once you're integrating with Drupal in the in the setup and tear down. It it's quite nice here way in the back. >> Can you do set up tear down? >> Uh, so the question was, can you do setup and tear down for a group of tests? Um so that's now we're into the realm of

PHPUnit um and not DTT. Uh PHPUnit provides um a little bit of functionality like that. There's setup before class um which lets you do a little setup uh for all of the methods in the class. Um, and there's the Bootstrap file I showed you, Bootstrap fast. That's set up for the whole um, run. Um, I can't think of setup for the whole group of tests except for

um, you can have a shared class that gets inherited. You can have traits that provide a setup method. You can have one setup method that calls common code. Um, and so there are different ways to share code um that you call from setup. So I think it's possible. It's kind of a oh code code organization question. Yeah. Right here. >> When you're writing functional tests using PHP

unit, it's possible to end up in a situation where you have a lot of junk that's left over because your code has actually bombed out unexpectedly. within the code itself, not not in a not a recoverable way. Is does DT do anything to help address that particular problem or is there still going to be the possibility of having lots of tables with funny names left over? >>

Yeah. So, the question was um if your test gets a fatal error or you stopped it manually um and it didn't get a chance to tear down and do all of its cleanup, is there a way for DTT to do cleanup, you know, after the fact? Uh there is no builtin way to do that. Um, you certainly could look at um the highest number nodes and blow

them away. and um, presumably there could be like a field or some way to we could keep a text file of the entity IDs that get created during the test. And so you could manually go to that tech test file and do cleanup. Um, it's not a bad idea. I've never really needed to clean up so badly that I was willing to solve that problem. Um, but

I've had that annoyance. So maybe maybe it's not such a bad idea. Um, you can also have like modules that are enabled that aren't supposed to and then your configuration sort of out of whack. And yeah, I could see the I could see some some benefit for that for sure. It's a good idea. Anybody want to talk about how you're using DTT today or how you might

use it on your site? Okay. Uh, all right. I think we have five more minutes. So, I have one more thing that I can show and talk about here. Um, we have something called the triple trait. um not an imaginative name but uh I just wanted to um talk a little bit about this you know very core feature this came into the very first uh instance of

Drupal test traits uh here's what it does um it should be called the Drupal bootstrap trait uh so that's what I've called it for the purposes of the slide here um and it has a function called setup Drupal this is called by some of the other traits. Um and this is what we do in Drupal test traits. Um where Drupal core itself wipes your database and reinstalls

Drupal using the minimal um in install profile. Um this is basically what we do. We don't do any of the reinstalling. We just bootstrap Drupal. Um so this is why Drupal test rates is so fast. Um because instead of tearing down and setting up a Drupal, all we do is bootstrap a Drupal. Um and this is what we do to bootstrap the Drupal. We find the Drupal

root um using Drupal finder and uh then we build up a server array. We create a request. We create a uh Drupal kernel and uh we change to the Drupal root directory. we call the kernel's boot and prehandle methods and we set the container to the container that the kernel made. Um, so this is super fast. Um, and this is how you know this is this is

the core of Drupal test traits. It's basically it doesn't do a lot of things. That's its magic. Um, this is the same sort of bootstrap that Drush does. This is the same bootstrap that other tools do that um kind of manage and uh so yeah, I don't know if anyone has a question question about this part um or anything else, but um if not, we can just

uh adjourn a couple minutes early. Oh, we got someone in the back here. Thanks. >> Drupal, that's the name of the function in the code. I can go look at that. >> Uh it's called setup Drupal. Yes. All right. Thanks for coming everyone. This is the QR code for submitting session feedback. I will look at that and be better next time. All right. Thanks everyone.