Talking Drupal #557 - Test-Driven Drupal eBook

[00:00:00] Nic: This is Talking Drupal, a weekly chat about web design and development from a group of people with one thing in common: we love Drupal. This is episode 557, Test-Driven Drupal E-book. On today's show, we are talking about test-driven development, e-books, and Drupal with our guest Oliver Davies. We'll also cover Juicer Social Feed as our module of the week.

Welcome to Talking Drupal. Our guest today is Oliver. He is a software developer and certified Drupal expert with 19 years of experience. He previously worked on the Drupal Association and specializes in code quality, automated testing, and test-driven development. He currently works with Transport for Wales and for various freelance clients.

Welcome back to the show, and thank you for joining us.

[00:00:50] Oliver: Thanks for having me back. Yeah, I think it's my fourth time on the show now, so it's, that's pretty cool.

[00:00:55] Nic: Yeah. Fourth time. I'm Nic Laflin, founder at nLightened Development, and today my co-hosts are Scott Falconer, Senior Director of Drupal Applied AI and Agent Success at Acquia.

And as usual, John Picozzi, Solution Architect at EPAM. Welcome back.

Okay. One thing we haven't fully worked out, bear with me, is switching scenes because it's different tabs. And now to talk about our module of the week, let's turn it over to Martin Anderson-Clutz, a product marketing manager for Drupal at Acquia and a maintainer of a number of Drupal modules of his own.

Martin, what do you have for us this week?

[00:01:38] Martin: Thanks, Nic. Have you ever wanted to embed social feeds into your Drupal website? There's a module for that. It's called Juicer Social Feed, and it was created in March of 2026 by, uh, Denis Umarovic, AKA DrupalChilli on drupal.org. Uh, it has a 1.0.2 version available that works with Drupal 10.3 or 11.

It is actively maintained. In fact, that latest version was created just today. For documentation, there is a README file in the project, and it has no open issues, and it is officially in use by four sites according to drupal.org. Now, this module embeds an aggregated social feed, uh, social media feed from juicer.io directly into Drupal as a configurable block.

It natively supports content from Instagram, LinkedIn, Facebook, X, TikTok, Blue Sky, YouTube, and more. Now, traditionally, displaying feeds from those kinds of platforms requires creating developer accounts, managing rotating OAuth tokens, and keeping up with constantly shifting API restrictions. Juicer handles all API authentication on its platform, shielding your website from sudden breaking changes by individual social networks.

To use this module, you will need an active account on juicer.io. They offer both free and paid tiers depending on how many sources you want to aggregate and how frequently you need the s- the feed to sync. The module is created and maintained by the official juicer.io team. That should ensure that the module is closely aligned with the product's features and any potential API changes over time.

The embedded feed is made available as a Drupal block to make it easy to control where it should appear on your site. When placing the Juicer block, the UI exposes several user-friendly settings. So feed slug is where you add the unique Juicer feed ID to establish the connection. The post limit controls exactly how many items will populate initially.

It has, uh, source filtering, so if your Juicer, uh, feed aggregates five networks, but you only want to show LinkedIn posts on a specific page, you can filter down to a single network right inside the block settings. It also has SEO or semantic controls, so you can set title or s- uh, subtitles to have the appropriate heading level, uh, so H1 through H6, to ensure your pages remain semantically correct and accessible.

Now, I did get a chance to test out the module and the service today, and I can tell you from experience, it's a huge improvement to having to create and pull in feeds directly. I did notice that the block didn't show up in Drupal Canvas component library, but I was able to determine that two lines of code to declare the block as fully validatable were all that was needed.

So I opened a feature request to add that, and it was merged in and a new release cut in less than an hour. So it's now Drupal Canvas- Oh, wow ... compatible as well. It's worth pointing out that the standard, uh, Juicers embed script loads, uh, via HTMX, which conflicts with the version of HTMX included in Drupal 11 Core.

As a result, the module fetches a feed HTML directly from the Juicer API and includes a minimal HTMX shim to prevent errors. Now, John, you nominated this module, so why don't you start us off by telling us about how you got started using it?

[00:04:52] John: Well, that's a long story, Martin. I don't know if we have enough time for that, but I'll, uh, I'll try to give the shortened version.

So, um, I don't know, probably like two, maybe three years ago now, I was looking for a way to kinda get all of my social feeds together on my, um, my personal website, and I was like, "Man, I do not wanna wire this up myself," because, you know Things change. Instagram changes, LinkedIn changes, API changes, access changes, all these things.

Didn't wanna have to deal with them. So like you said, I kinda went out to look for a service. I looked for a service that had a Drupal module. Um, Juicer had that, but it was not an official module from the actual company that produces the product. It was a, a community, uh, contributed module. Um, I used that module for actually a long time, so I s- I implemented this, like I said, two or three years ago.

I used it for a very long time. More recently, I wanted to upgrade my site to Drupal 11, and I was like, "Ah, the module doesn't support Drupal 11." Jumped into the issue queue for the original, uh, Juicer module, um, which I believe the, um, slug for that is Juicer IO as opposed to just Juicer. Um, but, uh, yeah, long story short, I jumped into the issue queue, didn't have enough time to, um, work in the issue queue to try to update the, the community-led version of the module, and then one day, like magic, I found this module.

Um, so last weekend, maybe two weekends ago, I, uh, installed this module to see how it worked. It worked great. It brought in, um, the Juicer block. It actually brought in some of the newer features and stylings that they use in, in their, uh, in their, in their presentation of your social feed. Um, so that was cool.

And it's Drupal 11 compatible, so it kind of like jumped me off into a whole update path for, um, Drupal 11 greatness, so appreciate that. And it looks like, uh, based on your, uh, merge request, uh, your issue merge request and new release that they're very actively developing this. So the, that's pretty, that's pretty awesome.

Um, but yeah, uh, I think the service is great. I actually pay for the service. Martin and I were having this conversation before the show. Um-

[00:07:20] Nic: I was gonna

[00:07:20] John: say ... for my, for my personal site, uh, I usually try to go with, uh, like freemium as much as possible because, you know, I'm, I'm cheap. Um, but uh, I actually do pay, uh, Juicer because I have more feeds that I wanna bring in.

So in order to get, you know, more feeds, I needed to, needed to pay a little bit of cash, but you know, well worth it. It brings in, um, I mean you can go to picozzi.com, you can see it in action right on the homepage there, but, uh, brings in all of those services. I think I use it for, uh, YouTube, LinkedIn, um, let's see, what else?

Uh, Instagram. So quite a few different things. Uh, highly recommend.

[00:08:01] Nic: I, I will say that as somebody who, um- Somebody who has integrated with these different tools in the past, it is a bear. And, and to be clear, with Juicer, I think things do still break just because the upstream systems change their rules all the time.

[00:08:21] John: Sure.

[00:08:22] Nic: But Juicer shields you from that, and you don't have to, like, go and fix that yourself. It's just it'll be broken for a day or so maybe, and then they figure out what the new- And- ... implementation process is, and then they fix it, and now you get that stuff fed in again.

[00:08:36] John: To be fair, you might not even realize that, um You had an issue.

It's, it's-

[00:08:43] Nic: Yeah ...

[00:08:44] John: there are different caching layers, both on, you know, my side, I use Cloudflare, but, um, they're, they also cache some things. So, like, you might not even see that it's, that it's busted. Um, and I will say prior to using this, um, service, I was using, like, the Instagram block module for, for, uh, for Drupal and some other, some other things to kind of build out my, my homepage feeds.

And yeah, you're absolutely right, Nic. Like, the Inst- Instagram changed its API, the block stopped working, had to go figure out, like, how to get around it. Oh, there's no way to get around it. It was just a hassle. So this definitely alleviates a lot of that kind of running around.

[00:09:24] Nic: Now, I, I- Yeah ... I wanna... Oh, go ahead, Martin.

[00:09:27] Martin: Oh, I was just gonna quickly add to that, that, uh, I can recall having had to set up a Facebook feed on a website for a customer years ago.

[00:09:36] Nic: Pain incarnate.

[00:09:37] Martin: And it was one of those things where you have to get, like, the Facebook developer account and then register the app. Yep. And it was, like, a whole bunch of steps.

And then the crazy thing was, like, I left the company, and years after was getting notifications of, like, the application needs to be updated and all these different things. So it's, like- Yeah ... something that's not even just a one-time hassle, but like, you know- Yeah ... a lot of ongoing work- Ongoing ... for, for each of those, yeah.

[00:09:56] John: Ongoing hassle.

[00:09:59] Nic: Yep. I, I wanted to pivot really quickly, John, 'cause I know that this was one of the last things to get you to Droo- to Drupal 11. Um, once you, once you updated this, how long did it take you to update the rest of the site to Drupal 11? Was it a... You know, do you do it in an afternoon? Well- Do you do it in a couple of days?

[00:10:18] John: Geez, Nic. Thanks for asking. I actually just wrote a blog post about my Drupal 11 upgrade experience. Um, and I will put the link in the show notes. Um, but to answer your question, uh, more directly, um, it was actually super quick and easy. Um, you know, I was able to upgrade to Drupal 11 probably in, like, a, an afternoon once I had, like, kinda cleared this hurdle.

Um, I was using upgrade status and, you know, I g- I was, like, at, uh, I think this module was one of the last hurdles and, and at that point, I was at, like, maybe 96 or 97% in upgrade status. Um, one of the other issues was, uh, upgrading to, uh, PHP 8.4. Um, so I was able to do that, had some issues there with some modules not have- being 8.4 compatible, so I had to apply some patches.

But, you know, after I to- a- after I did those things, um, I was a little bit closer. Um, the last thing or the last hurdle was I actually had to upgrade, upgrade Webforms. So as part of my upgrade path, I was like, "Oh, you know, uh, contact, uh, core contact is gonna be, like, deprecated. I'm just gonna move to Webform," so I moved to Webforms.

Um, but there's a new version of Webforms for- Um, I wanna say it's Drupal 10, 4, and 11. I could be wrong. Let me double-check. Um, but- Yeah, it sounds

[00:11:44] Nic: right ...

[00:11:45] John: um, yeah. So once I updated Webforms, I was, like, good to go. I followed the directions on drupal.org for, um, you know, upgrading, upgrading your site from 10 to 11, and, you know, it was, it was quick and easy.

So it was pretty much like an afternoon- afternoon effort, I think. Um, I'm sorry, it's 10, 3, and 11, and that's, uh- Yeah ... Webforms 6.3.0, release candidate one.

[00:12:11] Nic: Oh, nice. There's finally a 6.3. Okay. Uh, b- back to Juicer. I had one final question for you, Martin, about the HTMX stuff. Is that, is that something that you think there's a plan to remove that shim once it's 11 only, or is it, is it just there's a conflict between how they work, and the, and the shim is the way to fix that, and it will stick around?

[00:12:33] Martin: At least my interpretation was that it was actually related to the HTMX that is in Drupal Core. So, um, I don't know if maybe the newer version of HTMX that they're working on getting into Drupal Core might fix the incompatibility. But, um, I think it would be interesting to see, yeah. Obviously, it would be ideal if they, they didn't have to sort of use a separate method specifically for Drupal, but I don't know.

It's also possible that, that some of the cool things that you can do in the block configuration to change the actual feed contents, I don't know if those would still be available with sort of the native HTMX method either. So it's possible that we actually get some benefits from the current approach.

[00:13:13] Nic: Okay. Sounds good.

[00:13:15] Martin: Yeah.

[00:13:15] Nic: Well, thank you, Martin. As always, you had a- another good m- great Module of the Week. Um, how can folks connect or suggest another module of the week for you?

[00:13:25] Martin: So we are always happy to talk about candidates for Module of the Week in the Talking Drupal channel of Drupal Slack, or folks can reach out to me directly as mandclu on a variety of Drupal and social channels.

And also, a week from tomorrow, so June 17th, I will be on a webinar with Tim Lennon of the Drupal Association, talking about some of the new and exciting things coming in Drupal 11.4, as well as how to get your site ready for Drupal 12. So hopefully some listeners will, uh, join us then.

[00:13:57] John: I, I signed up for that one, so I look forward to, look forward to listening in.

[00:14:02] Martin: Right on.

[00:14:04] Nic: Awesome. See you next week. Thanks.

[00:14:06] Martin: All right. See you then.

[00:14:11] Nic: All right. Uh, so before we jump in, Oliver, we do have a couple of comments from listeners. So Fernando dos Santos says hello from Brazil, and he's curious about, uh, what's going on with your newsletter, if that's coming back anytime soon.

[00:14:29] Oliver: Yeah. So I was doing a daily email newsletter for a while. I've sort of retired it and put it into my blog now.

So you can still sign up for it through email and RSS and JSON. So it's all still there, and it's just going out through a different medium now.

[00:14:43] Nic: Perfect. And hello, Rajab. Thank you for, uh, thank you for joining us as well. Okay, before we, uh, jump in, can you remind folks what you mean by test-driven Drupal?

[00:14:56] Oliver: Sure, yeah. It's essentially is a play on the TDD acronym. So test-driven development is the common term, terminology, um, so TDD. Um, I've adopted it myself for talking about test-driven development, specifically within Drupal, so TDD being test-driven Drupal, and I've sort of used that for a few different things at, at, at this point.

My original idea was to do some sort of e-book or course, uh, at, at the beginning, and then when I've given talks, workshops, and things at, uh, meetups and conferences and, and DrupalCon. Um, I've adopted the name also for the, the talks and the workshops I've been doing. So it's sort of been used for a few different things now.

But yeah, essentially it's that idea of doing automated testing in Drupal. Uh, so TD, BD, D, I guess, if you want to be technical about it.

[00:15:47] John: It's a lot of- Yeah,

[00:15:47] Oliver: no ...

[00:15:48] John: it's a lot of acronym right there. Um, so for those folks that may not know, I know a lot of the developers on the line understand why tests are important, but can you, can you explain why tests are important or test-driven development is important?

[00:16:05] Oliver: Yeah. So I guess, technically, they're two different things. So you could be doing automated testing without test-driven development. Um, so yeah, they both, both are separate. Um, but it comes down to confidence for me. So as a, as a developer and as a module maintainer, I want to be confident that the work that I'm doing, A, works and meets the criteria and the requirements that I, I intended, uh, and also that then it continues to do that over time and that I don't potentially break something, like in a future release or, or whatever.

So everybody does testing, right? Um, but most- mostly it's all done manually. So as you're writing some code, you'll go into a browser and you'll maybe refresh the page or fill in a form or, you know, everyone's testing it somehow. The problem then is that you don't always go back and test that again for every other release, right?

You can be testing for new things you've done in that sprint or in that release or for that new version, uh, module version. The nice thing about automated testing is that those tests will live essentially forever in the code base and will get rerun for every release or for every commit as you, as you want to.

Yeah. So yeah, it's, it's me looking at it going, "I expect this thing to happen, and I expect this outcome for, um, from, you know, some event happening. Is that the case? Yes." Um, so I'm replacing that with an automated test rather than a, a manual test. Uh, and then yeah, it's just nice that you can, yeah, run that- Again, again, again, over time, um, if you've got things like CI pipelines for, um, GitLab for, for Drupal modules, it's great 'cause it shows up on the little project page as well.

So all your tests pass, you get a nice green tick on there. Um, yeah, and it's just that, you know, I like knowing that the code I wrote still works again several months after

[00:18:01] John: I got a dumb dumb question. I really say I think it's a dumb dumb question. Sure. Uh, are you write... So like i- you know, specifically let's talk about Dr- test-driven Drupal, right?

Are you writing tests before you write your actual module code? Like, are you, are you writing those tests and then through your module code y- solving for those tests? Or is it- Mm-hmm ... kind of the reverse?

[00:18:27] Oliver: Ideally, if you're doing TDDs and test-driven development, you would do the tests first. Mm. And there's quite specific things about that.

Um, so ideally you'd write enough code to make the test a test that fails, and then you write just enough code to make that test pass, and you go through that continuous feedback loop. Mm. So very short iterations. What you don't necessarily wanna do is write all the tests up front and then write all the code afterwards.

It's about keeping the feedback loops very short. Yeah. And, um, yeah. But you don't have to do that, like you could write all the code first and then write all the tests afterwards, just not as interesting I find doing it that way around.

[00:19:08] Nic: Yeah. So apart from that- I think...

[00:19:08] Oliver: Sor-

[00:19:09] Nic: sorry, Scott. I, I just wanna, I just wanna highlight that it helps solve one of the problems that writing the test, that I sometimes run into myself writing the tests after.

Like, you forget an edge case or something that you, you coded around, but you don't write a, write proper coverage for. Like s- speaking of confidence, one of the things that's scariest working in Drupal Core sometimes, or in a project, a, a client project, is like there's something that you know you need to refactor, something complex.

Mm-hmm. You refactor it, you run the test, and nothing fails. That's not like, "Oh, I'm a great developer. I got it right and perfect the first time." That's like, "Oh, God, there's no test coverage of this. Now I need to figure out what's, uh, what's missing." And, and you can write test coverage for the changes you made, but it's very difficult to go back and write tests for the existing functionality because you don't know exactly what everything is covering.

The more complex, the more gaps there are. Mm-hmm. Um, so, you know, writing test-driven development still doesn't cover every, every gap because you still fall into certain traps, right? You're, you're testing the happy path sometimes, you're testing... You're still, you can still miss edge cases, so you still need to, um, spend time thinking about what you're covering, but it, it, it protects at least that happy path, which sometimes- Mm-hmm

gets missed when you write the tests afterwards.

[00:20:30] Oliver: Yeah. This is true. And yeah, I find writing the test first, if you're in that very short feedback life cycle, um, loop cycle, then you're only writing enough code to make that test pass. So that might be only one line, whereas if you're not writing the test first, you might write more code than you need to write.

Whereas TDD, you're only writing enough to make the thing work.

[00:20:53] Nic: Makes sense.

[00:20:54] Scott: One thing on this, um, just 'cause I have to pivot every conversation to be about AI. So a lot of what you're describing here sounds very, very similar to like a lot of the spec-driven development, the, the, the prompting and things there.

Um- Mm-hmm ... I know I personally have come full circle where test-driven development was always this thing that sounded great, and I understood why you would do it and just never actually found myself doing it. But in the world of like kind of prompt-based development, it is much more important and, and you see the reasons why.

And so, you know, part of my question is, one, are you doing anything with that? Um, and, um, you know, where do you see the future in relation to these kind of tools and the growth?

[00:21:32] Oliver: Yeah, that's a really good question. Like, and then I've seen AI tools generating tests and generating production code as well. Um, the qu- my first thing then is usually is it, is it generating the right things?

Because anybody could write a test that essentially says, um, that it's maybe not testing the right thing or there's no value in a particular test. Mm-hmm. Just because it's written by... It doesn't need to be AI, it could be, um, by anybody. Um, yeah, just because there is a test and because it passes doesn't intrinsically mean that there's value in it.

Um, and some of the tests that might get written might be either very closely coup- very tightly coupled, so that means it's very difficult to refactor later on, so I would try and avoid that. And it's where you wanna draw that boundary. So I was doing some, um, front-end refactoring on a project recently, and the test started failing because the HTML class names changed in the template.

So it's, the functionality was still working, but the template, uh, was different. So again, that's not... Is that a failure? I guess that's where AI's probably not, um, gonna have the best idea, so that's probably more to developers to define where that line is.

[00:22:46] Scott: Yeah. And how do, how do you define where that line with a good test?

'Cause I know, um, it was really interesting as we were playing around with some of these tools, um, there was really good feedback I got on a merge request from Catch that had, there were some tests that were added, and he pointed out exactly this failure mode of, this is an overly defensive test, this is testing for something that is theoretically likely never going to happen.

So- Mm-hmm ... even doing this manually, how do you kind of, um, balance, you know, too much tests versus not enough tests?

[00:23:14] Oliver: Yeah, uh, it's personal preference, I guess, to a degree, and that's why I don't necessarily like things like, um, lines of code and code coverage as, as metrics. You will get tools and, and people that say like, "You need to have 100% coverage or 95% coverage."

Uh, and sometimes that for me just, yeah, gives the wrong sort of message. Um, I would rather look at it from more of a, a feature functional level and make sure it covers what I want it to cover. And maybe, like you were saying, maybe it doesn't cover all the edge cases originally, um- Yeah ... but maybe you do find more over time or maybe you can fix a bug and then add a regression test for it at, at the time as well.

Um, but yeah, I typically wouldn't use something like lines of code as a, or code coverage as a metric because, yeah, I think it gives the wrong, the wrong idea.

[00:24:04] Scott: Yeah.

[00:24:04] Nic: Yeah. That makes sense. I, I think this is one of the areas that, um- It, it, you know, some- sometimes doing it yourself is helpful because you get lazy at some point, right?

And so you're not gonna write 4,000 test cases for like a tiny little module where if something is just generating it, it's very easy to, to do that. Um, and you, and you run into another issue, which I- I don't know if there's a term for this, Oliver, where like every, every little change breaks a test and you have to update it.

So you're not, you're not like protecting the functionality, you're, you're protecting the test essentially. And that has the opposite effect 'cause you don't know if, um, something broke because the test was too hyper-specific or something broke because the functionality broke. And if the latter is happening, if it...

if you don't know when a test is important, the testing is useless. You're just burning CPU cycles for no reason. You- Mm-hmm ... you need the balance and tha- and that's one of the things, setting aside other Drupal core development processes, but one of the nice things about Drupal bug fixes is we require a test-only regression failure.

So we know, hey, this is the bug that the community agreed on. Somebody fixed it. We at least have a test to make sure that that particular piece doesn't, doesn't revert. Those kinds of tests are very, very... Like we, we know that it's scoped to that. Um, that's not to say that Drupal core doesn't have the other type of test in it.

It's a very big project with a lot of people. I'm sure I've written tests that test the, the specific, uh, the specific structure rather than the actual functionality in the, in the past, right? But, um, it's very difficult, uh, just like, you know, AI-generated code is very difficult to grok the whole thing. I think tests are...

Because tests are inherently different, they're even harder to understand. Um- Mm-hmm ... and when they're AI generated, they're even, like, they're even harder to know, is this testing the actual functionality? Is... It takes more time- Yeah ... to understand, to review. Um, but it's almost more important because if you're, if the tests are useless- That w- why, why are you burning CI cycles, right?

Why are you, why are you using that energy? You're slowing down the development. Um, and, and understanding that line, that's not an easy thing. I, I'm not saying that everybody should even know that line. It's very, it ... Like, there are things that sometimes Burdier or Catch point out, and like, oh my God. Or Don, you know, the...

Tons of people point out stuff, and it's like, "Oh, I didn't even think of that," or, "I didn't even realize that." Never mind getting into the discussion of a kernel test versus unit test versus a functional test, right? There, there's layers to it, but yeah, it, it's very important to understand that you're actually testing functionality you wanna keep.

Um, I... B- before we get into your book, Oliver- Okay ... I will say, um, I've started reading a book called Code That Ships. It's a f- it's a pay what you want book, I'll put a link in the show notes, that was recommended to me by Burdier, and one of the things that they say about testing, and I'd, I'd like to hear your opinion.

Um, and I'm gonna paraphrase here, it's not as strongly put as this, but they basically say, um, when you're developing, it kind of takes the opposite take of tester from development. They're saying that you shouldn't write tests for things until it's a feature you wanna keep when you're, um, writing a product.

Mm. So Drupal is a... Drupal core itself is different because Drupal core is kind of a library that everybody relies on, but when you're writing functionality for a given website, you shouldn't write tests for it until you know that you've gotten the feature right. Because you might write a whole feature and then tomorrow they say, "Oh, it's not quite working the way we want it to.

Change it to do X, Y, Z." And if you're writing tests for it every step of the way, those tests are just extra development cycles you have to handle. But let's say- Yeah ... you write the feature, you get to, it's been two months, that feature is set, that's when you wanna write the tests. I, I, I'm curious if that's something that you follow, or do, are you s- do you strictly follow test-driven development as a, as a developer workflow?

Or test-driven Drupal,

[00:28:19] Oliver: I suppose? It's, it's an interesting p- point. Yeah, I can see, see what they mean by that. I think that's a really interesting idea. Um, I've also seen with people that just, like, "I'm not really sure what it is that I'm writing yet, so I'll not start with a test because I don't really know what I'm testing.

Like, I don't really know what it is yet." So I have seen with people, and I've done it as well, where sort of spike out a feature, and then sort of feel, see how I feel about it after a while. "Is this really what I wanna do?" And then Git reset the whole branch, and then start again, and then start doing the t- like, what did I learn from that?

And then start the- Okay ... TDD cycle with the tests that I learned from before. Um- There's no, I guess, I don't think there's a right answer in terms of whether you always have to write the test first or afterwards. But I do think there's, by having the test there, whether, yeah, whether you've wrote it before or after, um, there are advantages to both, both ways.

But yeah, just having the test is, is the eventual goal.

[00:29:16] Nic: Very cool.

[00:29:23] Scott: Perfect. Um, so with that, kind of getting back to the book, what, what led you... You know, you're writing tests, you drink code, and then you wake up one day and you're like, "I'm gonna write a book." Um, how'd that happen?

[00:29:34] Oliver: It was a while ago, so I, I can't really remember. It was quite a while ago. Um, I remember being sort of inspired by things like Ansible for DevOps, which is Jeff Geerling's book that he worked on, yeah, probably quite a while ago.

Um, Adam Wathan did a test-driven Laravel, um, course, but also did a book called Refactoring to Collections. Um, again, that's probably quite a while ago. And so I definitely remember being inspired by products like that, and I remember thinking, like, what can I maybe do in, in a similar sort of way? Um, testing was always something I remember looking at and going, "I want to learn how to do that."

So it sort of made sense to, to put the two things together and try and put out some of the resources that I maybe couldn't find or couldn't... or weren't there when I was trying to learn it. Um, yeah, but yeah, uh, I've always written a lot of blog posts and, and given talks and things, so it seemed like a- another good way of putting out information, um, like that.

Uh, 'cause there's only so much you can cover in a, in a blog post or, or a talk. Um, I did do, uh, an email course. So I set up a, essentially a, a newsletter that you got an email a day for 10 days just covering a different step. But again, there's only so much you can really go into. Um, there's only so much depth you can go into per email, and then you don't wanna turn it into an email a day for a month, which you probably could do with a, with a topic like this.

So I thought, um, I would move it into, um, s- like, an e-book situation, um, format, and then I can constantly be making updates to it, and then also just, like, adding in new sections and things that just weren't enough space to do in, in, like, an email course format- Yeah ... or, or a short blog post format. So that's how I ended up on the e-book idea.

And it was sort of the original idea that I've just sort of just come back round to now. So it's sort of where it, where I wanted to be originally in the, in the first place.

[00:31:32] Scott: Would you recommend other people do it, in hindsight?

[00:31:36] Oliver: Yeah, it's... I quite like... Like I say, because I write a lot of blog posts anyway, and I think for me it's almost like this, like a blog...

a book like this is more a collection of blog posts. So it's like a, a, a series of blog posts really. So yeah, anything that I think, yeah, is maybe more than a couple of blog posts, I think it's a good way of collating that information and sharing it with other people.

[00:31:56] John: Would you, uh, ever consider moving it from an e-book to a physical book?

[00:32:05] Oliver: Possibly. You know, I think that's something I was... one of the original things I was thinking of, because I know the, the Ansible for DevOps thing was the actual physical book as well. And I think that was one of the things where I'm like, "Oh, I need to get a, a front cover design. I need to figure out how to print the thing."

All these things that originally, um, sort of turned me away from, from the book idea. But there are sort of, um, like, on-demand printing options and other things as well that I'm aware of. So- People can, could print, um, copies if they wanted to. But yeah, we'll see. Uh, at the moment, the e- it's still, like, the email course content just in a, an e-book format, so I n- I need to do some new versions of it.

Uh, and there, there's definitely stuff like Drupal 11 changes I maybe need to make. There's things like adding in, um, Drupal test rates that I didn't cover. That was, there was not enough space in the email course to cover that. So I think there's a lot more that I would want to do with it, but once it's printed, you can't really change it then without releasing another copy of the book, which is why I quite like having, um, like the PDF versions or the HTML versions, 'cause you can constantly keep them updated over time and just do very small s- micro releases of things rather than have to print another version- Yeah

of a book that people then need to buy another copy or, or whatever.

[00:33:24] Scott: The, the, the publishing process, so on mine I did it through the Amazon publishing. It, it, it's a fun exercise to go, like, the cover is the hardest. You spend the most time on that. But yeah, not being able to update it, you know. Mine is a year old now in the world of AI, so I will not open it and look at it.

I'm afraid of what I said in that book. And, and it's, it's the same psychological thing. It's like, now it's a year later and there's so much to update, so, um-

[00:33:46] Nic: Yeah So Oliver, can you tell me who, who the e-book is for? Is if, uh, it, I mean, I think it's kind of obvious that it's for developers, but is it more for- Mm-hmm

beginners or advanced developers? Do you have to know Drupal already? Um, who, who's the book for?

[00:34:04] Oliver: Yeah, so primarily developers, I think, as well. But I think they're not necessarily advanced developers. But, uh, you know, when I've done this as, as c- I did a workshop for Drupal Camp London just before COVID, and we had, um, people, like, well, beginner people in- involved in that as well.

And I think the concepts sort of apply regardless of whether it's, um, you know, maybe not even a Drupal developer, or if you, if you're using... It's PHPUnit-based, so if you're used to using something like Symfony or Laravel, you're gonna be familiar with, with those tools anyway. Uh, and a lot of the concepts even go from other programming languages anyway, and the structure of a test of, with the whole arrange act assert thing is the same, you know, if you're writing it in JavaScript or Python or wherever else.

So, um, yeah, I feel there's a lot of transferable skills there- Mm-hmm ... um, that people can, can bring over.

[00:34:55] Nic: How do you keep up with the changes in PHPUnit? Because PHPUnit is very complex. I mean, it-

[00:35:01] Oliver: Mm-hmm ...

[00:35:02] Nic: it solves so many problems for testing. Yep. It's a great project. But the, the Drupal community has had... It, it's taken a lot of work by a few maintainers to update from, I think, 9 to 10, and I think now we're getting ready for PHPUnit 13.

Um, h- how do you kind of keep up on kind of an external project like that and make sure that you're keeping tests up to date so that you can use the new features and not, uh, break old tests just because it's a different format or something?

[00:35:36] Oliver: Yeah. It almost can test, test inception at this point 'cause you've got PHPUnit being the testing framework, which itself has its own set of tests that that it's running against.

Um, and they've got their own, um, sort of backwards compatibility promise and everything there as well. Um, the only issue I can really think of is one of the major versions, or is a minor version, and they added, um, a void return type to the setup method, um, which broke things, so I had to go and add, add void to, to my setup methods.

But in general, I haven't constantly have had that many issues personally. But then I also try and run, because I'm running these tests in, like, CI pipelines, they run every time I'm doing a commit and, and pushing that commit. So maybe I'm just- Yeah. Yeah, maybe I'm not seeing that. If I've, if I was only gonna run them maybe every couple of weeks or every sort of month or so, maybe I would, uh, I'd see them all in one go.

But maybe because I'm doing them so often they sort of maybe just zoom past.

[00:36:35] Nic: Hmm. Interesting.

[00:36:40] John: So, huh, this, this question seems a little bit, um, maybe obvious, but I'm wondering, like, what can people expect to learn from the e-book? Like, right, so if I pick this e-book up and like, I kind of know my way around, like, developing for, for Drupal, but like what, what g- by the time I'm done with it, what can I expect to- Mm-hmm

to get out of it?

[00:37:06] Oliver: So my first idea when I did the email course was to start off with nothing and go to a situation where you've got a Drupal site and- Mm ... a test in, in the first, um, s- episode or the first edition, the first day, the first lesson. Yeah, lesson's probably the best, the best word. So it starts off with, uh, how to clone, uh, and set up a new Drupal project- Mm

from scratch, uh, how to create a new custom module, and then how to start off by writing a test for that module, and how to get that passing. So m- my example in the test i, in the, the, in the course was to build a, a blog page, which normally of course you do with, probably do with views or something. But I wanted to find something simple that everybody could relate to and identify with, and something that wasn't too complicated.

Whether I changed that in another, in another version, I'm not really sure. But yeah, I thought it was important to start off with something, and it covers basic th- the, the more basic things like how do you structure a test? Like what d- where do they live? What is the file name called? Because there's, there's conventions around.

Mm-hmm. It has to end with the word test and .php, and each test method had to start with the word test. So there's, there's some conventions that I introduce right at the beginning and then obviously how do you run them, um, that there's the php did command, but in early versions of Drupal Core there was like a run test script as well.

So I cover all that at the beginning and just as we go through the book then, and through the email course, then it builds on that and adds more features to it-

[00:38:43] Nic: Mm ...

[00:38:43] Oliver: as, as we go. But yeah, now it's in the e-book format, I can just ma- yeah, do a lot more detail and add a lot more stuff to it as, as we go. And the limits, uh, limits are endless, or there aren't limits now.

I can, I don't have to worry- So, so for the- ... about how keeping it to one email length.

[00:38:59] John: So for the Drupal setup piece, are you, uh, using D Dev there or-

[00:39:06] Oliver: I think it might be DDEV or it might just be running sort of PHP, um, local server or something with an SQLite database.

[00:39:14] John: Okay.

[00:39:14] Oliver: Um, I'd have to go back and check, but, uh, no, DDEV is pretty much I think the de facto thing, so everybody's, um- All right

familiar with it. Um, but that does come with some slight differences with how you'd configure PHP unit because it's Docker-based.

[00:39:29] John: Yeah.

[00:39:30] Oliver: So normally if you're just running a PHP server locally, you would point it at, um, local host or 127.0.0.1. Whereas in a Docker format, you need to point it at the web server or the PHP container that it's running in, so you need to use the name of, of the container.

Um, so I think I definitely cover that in... I've covered it in the talk that, yeah, if you're running DDEV or, and I've done it in the workshop, if you're running DDEV, it needs to be this. Mm. Um, but yeah, not, uh, not everybody is using the same thing, but I guess most people are probably using DDEV at this point.

So I think I cover both.

[00:40:08] Scott: Okay. Perfect. Um, you kind of touched on this a bit, but how often are you updating the e-book, and how often would you prefer or like to update it?

[00:40:18] Oliver: So I've, at the moment it's just, let's just say this is version one, so it's everything but when I decided to re- to sort of retire, it's the same platform I was using for the, um, the, the daily email thing.

I've sort of moved off it now. Um, so the first version of the ebook is that content moved onto the ebook format and published. But as time goes on, like now I can update it as much as I want because there's some things in there, um, Drupal test traits, I definitely want to add a section in about. So it's something I can update as much as I want, and the theory, um, I've heard about is, um, perpetual publishing, so you're not tied into, you know, big release cycles or publishing big major versions.

I can make one small amendment and, and add a note or something and just, and publish a new version of it very quickly. Um, so yeah, that's something I would like to do and make it... I can change it now into more of an ebook format and really think about how I would start it. If I was gonna start it again now, how would I do it?

But I don't want to lose everything I did in the first version, so yeah, I'm gonna try and think of the right, the right approach of, of doing that. But I didn't wanna lose the original version from the email course because a lot of people went through that and found it useful, so I thought I would keep that around as, as version one and then start to look at how to, to migrate a, a newer, a newer version.

But- Yeah ... definitely something, just test it all again with Drupal 11 and make sure that all still works because there have been slight differences as I've gone through, um, major versions of, of Drupal versions with it. Um, so yeah, now I'm gonna... 'Cause I can just update that and I do have the source code, um, for it as an example, so I also might publish that if I haven't done that already, so people can use that as a, as a, as a reference point as well.

[00:42:07] Scott: I had big hopes with mine because you can just push out new updates, so I'm sitting strong at zero updates after a year. So watch out for that one. Life, life sneaks up on you.

[00:42:17] Nic: So- Yeah ... b- b- before I jump into the next question, I wanna say hi to Glorstein, uh, from YouTube, so thanks, thanks for watching. Um, something I like to ask whenever we have an author on to talk about their book is, um, what was the pro- the actual process of creating the ebook like?

Like h- what tooling did you end up deciding on? H- did, how many tools did you test, um, before you settled on kinda where, where you did? I, I'm always curious what the actual publication portion is like for- Mm-hmm ... kind of self-publishing.

[00:42:53] Oliver: Yeah, and this is one of the things originally where I was thinking, I've seen people build their own, um, tools and platforms for things.

Originally I thought, "Do I need to do something like that for myself? Do I need to have something I could write in Markdown or some other, um, sort of markup language?" Um, LeanPub is a site I've used and I've bought books from. Um, they've got their own editor that they're hosting tool that you can use, which I'm pretty sure is Markdown based.

So this is one of the original things why, um, and maybe didn't make it into an ebook in the beginning 'cause I was a little bit overwhelmed by all the different options, I guess. Um, the way I'm doing it now is using, um, AsciiDoc, which is very similar to Markdown. Um, so it's using an ADOC format and that has an option t- to generate PDF.

Uh, it will generate HTML and it will generate EPUB. So yeah, I'm using the one tool to generate three versions of the same thing. Um, all it- so it's all in plain text in AsciiDoc format. I can keep-

[00:43:56] Nic: Okay ...

[00:43:57] Oliver: the, the code alongside the pages, which is nice. Um, and it gives me also maximum sort of reuse if I'm using it in a presentation deck or whatever else as well.

I can copy pa- copy and paste things across from that, so. So is

[00:44:10] Nic: it one giant file or is it like a HTML... Is it like an HTML tree of or XML tree of- Plain text

[00:44:17] Oliver: Um, it could just be one file, but it does support like includes and things as well. So I do have it split out into different, different sections, I think, for, for different areas.

So in this case, I've probably got one per chapter. But, um, some of the other ones I've been doing are split down quite a bit more than that- Okay ... just to try and keep things organized. But, um- When

[00:44:37] Scott: you- Yeah ... when you get to physical publishing, um, I, I ended up using a thing called Vellum. It, it- Okay ... it's pricey.

I think it's a couple hundred bucks, but it's, it's well worth it. But it, this was eye-opening for me. Like, published books are mostly now just PDFs you send over. Um, but- Yeah ... yeah, it, it was interesting going from, I had the e-book and it was like, "Yeah, this looks fine." And then once you, like, see it printed on a page, you're like, "This looks like I printed this off myself."

Yeah. And so the tools are nice. And what's cool about Vellum is like pictures and layouts, and you can do like coffee table books and stuff. So again, I had high hopes of doing all sorts of publishing once I figured that out. But if you're into photography or art or anything else, um, Nic, I expect a Lego Drupal book from you, um-

[00:45:20] John: I feel- I feel like the test-driven Drupal, uh, coffee table book is just a natural evolution here.

Like tests gone wrong, tests- ... tests running for too long. Like, just all sorts of great, great stuff in there. Um- Yeah, sounds

[00:45:38] Oliver: great ...

[00:45:39] John: Oliver, I'm wondering if you have any, um, any learnings so far from creating, creating the e-book. Or, or starting down this road of, of kind of like e- e-book greatness.

[00:45:56] Oliver: Mm-hmm. I guess I have.

I mean, it's, I, I just like the idea that I can put things out there and, and share knowledge with people, and that's, that's probably why I do the blog posts and why I do, um, speaking at, at groups and things. Um, so- Yeah,

[00:46:11] John: you must really like it- I do that ... 'cause anybody that's committing to a daily email, like that's a lot of- Yeah

that, that's passion right there.

[00:46:19] Oliver: Yeah, indeed. So yeah, I mean, it obviously it's one of the ones, the talks I did for, for Drupal Camp a few years ago was getting started with Drupal 8 module development, and this was probably very early on with the Drupal 8 development cycle. But it was a good excuse for me to go and learn a lot more about how the D8 module cycle worked.

So-

[00:46:39] Scott: Yeah ...

[00:46:39] Oliver: there's definitely been opportunities where I've found out stuff by writing the book that I didn't obviously know before, so I've taken some knowledge from it directly, uh- Mm-hmm ... in some places. Um, things like Drupal test traits I probably hadn't explored before, and I've spoken to Moshe about that on, on, uh, my podcast before, and since talks about it.

So yeah, there's definitely, uh, things that I've learnt, and I think as I look to my, to update this onto more D11, I know some of the core testing framework is also changing or has changed. Um, functional JavaScript tests have moved from Nightwatch to Cypress I think some time ago. So yeah, there'll definitely be an opportunity to learn more of that side of things.

And Drupal Canvas I haven't really looked at too much yet, so I think there's a whole load of stuff now that now it's, I've moved into this format that I can look at, at and, and try and share that knowledge with everybody else.

[00:47:41] John: I wanna take a moment and say hi to Selwyn who's, who's, uh, listening in on YouTube.

And you mentioned something really interesting. So we talked about how you're sending out emails. You're now got an e-book. You also just said that you had Moshe on your podcast. How often are you podcasting?

[00:48:00] Oliver: Um, I haven't done for a while. I'm taking a, a little bit of a break from it, but I think we did about 30-something episodes over the last couple of years.

So I've had Moshe on. I had, um, Jess Archer from the Laravel team. I've had Tim Lehnen from the Drupal Association, we spoke. Uh, who else have I had on? Quite a few people have come on twice, which was quite cool. Um, but yeah, the last time I was at Drupal Con, some people came up to me and said, "Hey, I've listened to your podcast."

And, uh, that was really cool. But, uh, yeah, on a little break from it at the moment, but maybe we'll pick those up again.

[00:48:33] John: Yeah, this podcasting thing is exhausting.

[00:48:37] Scott: Perfect. Um, any other kinda e-books on the horizon or any other kind of creative projects you're working on?

[00:48:44] Oliver: Um, this I, like I say, I think there's definitely some updates to do for this one, um, in terms of D11 and everything else.

Um, the other one I've been writing is Sculpin From Scratch. So Sculpin is a PHP static site generator. I've used that for my site I think since 2015, and I quite liked it 'cause it was using Twig, and I was learning Twig for Drupal 8 back then. So I've been writing that one for a little while. Um, I'm thinking of doing one on mob programming and pair programming, uh, 'cause I, I do enjoy doing pair and mob programming.

And I initially thought I would do, um, just a, a, a resource list or some ideas around that. So that's the really early stage of possibly becoming another, another book. And-

[00:49:32] Nic: So-

[00:49:33] Oliver: Yeah, I'm trying to see-

[00:49:33] Nic: Sorry, what is- ...

[00:49:34] Oliver: if I can get...

[00:49:35] Nic: Go. What is mob programming?

[00:49:38] Oliver: So, um, pair programming is where multiple people- Yeah

work on the same thing together. And mob programming is more than three people doing, doing that at the same time.

[00:49:48] Nic: Oh. Oh, mob, like a mob

[00:49:50] Oliver: of people. Mob programming. Yeah. Mob or ensemble- Oh ... or group program, team programming. There's lots of different terms for it. Um-

[00:49:55] Nic: That sounds

[00:49:56] Oliver: like

[00:49:56] Nic: pure chaos. But also sounds like it could be fun.

[00:50:01] Oliver: Yeah, it's good fun. So, so something I s- It- ... I've started trying to do in the, is trying to organize some, some Drupal mob sessions- Yeah ... and try to work on, on cool- I'm, I'm gonna

[00:50:10] John: try to organize- ... features using the mobs,

[00:50:11] Oliver: which should be

[00:50:11] John: fun ... Drupal flash mob sessions, where just random people- Well- ... get together and try to code something.

[00:50:19] Nic: Yeah, it's fun. Well, I'm, I'm thinking, Oliver, that it might be interesting to do a TDK Cafe episode where we m- if we can find a good... I, I feel like more than pair programming, mob programming really depends on the type of task you're working on. Mm-hmm. But I feel like that could be a, a very interesting- Yeah, that could be fun

TDK Cafe episode. Um, especially- Yeah ... if John is moderating. I think, I think that could be fun. John, John'll be in charge of the, uh, of the architecture, and then, uh, whoever, whoever's there can be in charge of the, uh- The multi-pair programming, I guess. That could be a lot of fun Yeah.

[00:50:57] John: No, I want the button on the left.

[00:51:01] Scott: Yeah. I'd like to see how that works with me and my friend Claude, and my other friend Claude, and my other friend Claude.

[00:51:05] John: Well, it's funny 'cause when Nic first suggested it, I was like, "Oh, this is fabulous. We'll have two developers. We'll have a architect that just barely knows how to develop, and then we'll have the AI guy bring all the AIs in.

And then... And we'll see what we come up with. Like, by the end it'll either be great or it'll be complete you know what.

[00:51:28] Nic: All right, Oliver. Before we close out the show, is there anything else you would like to share, uh, share with our audience?

[00:51:36] Oliver: Um, not right now. I don't think. The e-book is on my website. Um, so it's OliverDavis/tdd- I actually-

dot PythonTDD, which I'll put on the, we could put in the show notes.

[00:51:45] John: Sorry. I do have a question. The e-book is free? All of this content is free?

[00:51:51] Nic: Yes. Yep. Is there a way to pay for it if somebody wants to support you, or is it, is it just fully free?

[00:51:57] Oliver: Hadn't thought about it. I mean, I'm sure there could be if somebody wanted to, but no, it's, uh...

The email course was free, so it makes sense to, to put the e-book out there for free as well.

[00:52:07] John: All right.

[00:52:07] Nic: Cool. Well, as always, Oliver, thank you for joining us. It's been a pleasure chatting about, uh, test-driven Drupal with you. Um, maybe we can have you on a little bit sooner than on a four-year cycle it seems that you've been on.

Sounds great, yeah. I

[00:52:21] John: feel like our next topic might be Sculpin. Was that the, was that it? Mm-hmm. That was it, right? Yeah. Okay.

[00:52:26] Oliver: Yeah, yeah. Sculpin. Yeah.

[00:52:28] Scott: Also for topics, I would love to put out Lego-driven Drupal, so in the Talking Drupal Slack we were talking about- I know ... Legos and, well, and I followed up today.

There is the giant Lego DrupalCon still in the Acquia office. So I s- basically have Dries on to explain the complexity of, like, how he guessed the number of Legos in that and then how it was shipped, uh, from Germany to him. It's a, it's a pretty interesting story. But it still exists, it's very heavy, and it's very big.

So.

[00:52:56] John: Do you have questions or feedback? Reach out to Talking Drupal on the socials with the handle TalkingDrupal, or by email with [email protected]. You can connect with our hosts and other listeners on Drupal Slack in the Talking Drupal channel.

[00:53:12] Nic: And you, if you want to become a guest on Talking Drupal or our new show, TD Cafe, click on the guest request button in the sidebar at talkingdrupal.com.

[00:53:22] John: You can promote your Drupal community event on Talking Drupal. Learn more at talkingdrupal.com/tdpromo.

[00:53:29] Nic: And you can get the Talking Drupal newsletter to learn more about our guest hosts, show news, upcoming shows, and much more. Sign up for the newsletter at talkingdrupal.com/newsletter.

[00:53:39] John: And thank you patrons for supporting Talking Drupal.

Your support is greatly appreciated. You can learn more about becoming a patron at talkingdrupal.com and choosing the Become a Patron button.

[00:53:51] Nic: Awesome. And Oliver, if our listeners wanted to get in touch with you, had any questions, what's the best way for them to do that?

[00:53:58] Oliver: Contact me through my website. It says oliverdavies.uk, uh, or through drupal.org where I'm opdavies.

[00:54:06] Nic: Awesome. And Scott, how about you?

[00:54:08] Scott: LinkedIn at Scott Falconer, and, um, next week I will actually be at Acquia Engage Paris, so for anyone in the French Drupal community that's in or around Paris next Tuesday and Wednesday, uh, feel free to find me. I'd be happy to chat.

[00:54:21] Nic: Perfect. John, how about you?

[00:54:23] John: Uh, you can find me personally at picozzi.com.

Uh, you can find me on the socials and drupal.org @johnpicozzi, and you can find out more about EPAM at epam.com.

[00:54:34] Nic: Perfect. And you can find me pretty much everywhere @nicxvan, N-I-C-X-V-A-N.

[00:54:40] John: And if you've enjoyed listening, we've enjoyed talking.

[00:54:48] Nic: Awesome. See you guys next week. I was

[00:54:50] John: really, really going for, like, a Macho Man vibe there. I think I blew it.