PHP Alive And Kicking Episode 25 Sebastian Bergmann

PHP Alive And Kicking: Episode 25 Sebastian Bergmann 🔗 **Source:** [PHP Alive And Kicking: Episode 25 Sebastian Bergmann](https://www.youtube.com/watch?v=DCCGn4vurZE&rw_yt_language=en) > [!note]+ Document Notes > tags: #php #testing #phpunit #event-sourcing #test-driven-development > author: PHP Alive And Kicking > source: YouTube > reference: https://www.youtube.com/watch?v=DCCGn4vurZE > date created: 2025-01-04 12:00 > > # 🏷️ Title: PHP Alive And Kicking: Episode 25 Sebastian Bergmann >  ## 🧰 Action Inbox - [H1] Explore event sourcing testing patterns — given/when/then methodology for event-driven systems #event-sourcing - [H2] Investigate PHPUnit 13 array comparison assertions — eight new assertions for strict/loose array comparison #phpunit - [H3] Consider board games for technical training — domain-driven design and TDD teaching approach #training ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Sebastian Bergmann's Blog](https://sebastian-bergmann.de/) - [PHPUnit Documentation](https://phpunit.de/) ## 📝 Summary Sebastian Bergmann, creator of PHPUnit, discusses his journey from Amiga programming to creating PHP's most widely used testing framework. He shares his path into PHP development in 1998, the evolution of PHPUnit over 26+ years, and innovative approaches to testing event-sourced applications using given/when/then patterns that generate visual documentation. Key highlights include PHPUnit 13 features, code coverage improvements, and using board games as teaching tools for test-driven development. ## 📖 Main Content Sebastian Bergmann's programming journey began with the Amiga 500 in 1990, progressing through demo scene participation and bulletin board system extensions. His PHP introduction came in 1998 during a university internship when contacted by a former Amiga graphics artist needing server-side programming help. After trying Perl briefly, Sebastian found PHP intuitive and learnable within a weekend. PHPUnit emerged from Sebastian's need for a JUnit-equivalent testing framework for PHP around 2004-2005. Initially hesitant to publish his solution, he eventually shared it on cvs.php.net, leading to widespread adoption. The framework has evolved significantly, with PHPUnit 10 introducing an event-driven architecture and PHPUnit 13 adding enhanced array comparison assertions and mock object parameter matchers. A major innovation Sebastian presented is testing event-sourced applications using given/when/then patterns that map directly to domain events. This approach generates visual documentation aligned with event storming techniques, creating living documentation that shows system behavior through test execution. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/DCCGn4vurZE?t=0) — [H1] Introduction and guest setup - Key idea: Sebastian Bergmann joins PHP Alive and Kicking podcast - Evidence: "Today's guest is one of the speakers who has kindly agreed to come on" #### ⏱️ [05:30](https://youtu.be/DCCGn4vurZE?t=330) — [H2] Sebastian's PHP origin story begins - Key idea: Sebastian entered PHP development in 1998 during university gap period - Evidence: "That was in 1998... between I had just finished my military replacement service" #### ⏱️ [08:45](https://youtu.be/DCCGn4vurZE?t=525) — [H1] Amiga programming background - Key idea: Sebastian's programming foundation came from Amiga demo scene participation - Evidence: "Got an Amiga 500 in 1990 and an Amiga 1200... I was always fascinated by the intros, the cracks and the demos" #### ⏱️ [12:20](https://youtu.be/DCCGn4vurZE?t=740) — [H2] First PHP project and Perl rejection - Key idea: Weekend PHP learning enabled first server-side programming project - Evidence: "I tried my hands at Perl for one or two hours and then stopped... I tried PHP and was able to learn enough PHP in a weekend" #### ⏱️ [16:15](https://youtu.be/DCCGn4vurZE?t=975) — [H1] PHPUnit creation motivation - Key idea: Sebastian needed JUnit-equivalent testing framework for PHP projects - Evidence: "I searched for a solution for that in PHP... somebody must have already built that, right?" #### ⏱️ [19:30](https://youtu.be/DCCGn4vurZE?t=1170) — [H3] PHPUnit publication hesitation - Key idea: Sebastian delayed sharing PHPUnit for a year hoping someone better qualified would create it - Evidence: "For about a year, I did not want to share that with the world because I was still hoping that somebody else who is much better qualified" #### ⏱️ [23:45](https://youtu.be/DCCGn4vurZE?t=1425) — [H1] Event sourcing testing concepts - Key idea: Event-driven systems enable elegant testing through immutable event records - Evidence: "You keep a record of everything that is relevant to your domain as it happens as an immutable event" #### ⏱️ [28:10](https://youtu.be/DCCGn4vurZE?t=1690) — [H2] Given/when/then testing pattern - Key idea: Event sourcing tests express intent through readable given/when/then structure - Evidence: "Given that these events have happened in the past when I perform this command... then I expect that these other events have now been recorded" #### ⏱️ [32:20](https://youtu.be/DCCGn4vurZE?t=1940) — [H1] Visual documentation generation - Key idea: PHPUnit extensions can generate visual maps from event-driven tests - Evidence: "Get visual documentation out of running the tests that goes full circles to... a lot of sticky notes on the wall that are color-coded" #### ⏱️ [36:40](https://youtu.be/DCCGn4vurZE?t=2200) — [H2] PHPUnit 10 event system - Key idea: PHPUnit 10 introduced comprehensive event system for extensibility - Evidence: "PHPUnit just emits an event for everything that is relevant in the context of running tests... dozens like for anything that is meaningful" #### ⏱️ [41:15](https://youtu.be/DCCGn4vurZE?t=2475) — [H1] PHPUnit 13 new features - Key idea: PHPUnit 13 unusually includes new features in major release - Evidence: "The new thing about PHPUnit 13 is that there is something new... usually the first release of a new major version is rather boring" #### ⏱️ [44:30](https://youtu.be/DCCGn4vurZE?t=2670) — [H2] Eight new array comparison assertions - Key idea: PHPUnit 13 adds comprehensive array comparison assertions covering all strictness levels - Evidence: "There are eight new assertions that deal with arrays comparing arrays for identity and equality from very very strict... all the way to the other end" #### ⏱️ [48:50](https://youtu.be/DCCGn4vurZE?t=2930) — [H1] Code coverage serialization rewrite - Key idea: Sebastian rewrote code coverage merging functionality after 10+ years of frustration - Evidence: "I rewrote the code that serializes code coverage information... while solving all the bugs that have accumulated" #### ⏱️ [52:15](https://youtu.be/DCCGn4vurZE?t=3135) — [H2] Board games in technical training - Key idea: Board games provide excellent domain examples for teaching TDD and DDD - Evidence: "We are selecting a subset of the rules from that game and will implement these rules in a test-driven fashion" ## 📚 References - [Sebastian Bergmann's Blog](https://sebastian-bergmann.de/) - [PHPUnit Documentation](https://phpunit.de/) - [Event Storming Methodology](https://www.eventstorming.com/) - [PHP Architect Magazine](https://www.phparch.com/) ## 🗣️ Paraphrase - Sebastian's programming journey started with Amiga computers in the 1990s, progressing through demo scene participation to bulletin board system extensions, eventually leading to PHP development in 1998 when helping a former graphics artist with server-side programming needs. - PHPUnit emerged from Sebastian's university experience with JUnit and his need for similar testing capabilities in PHP, initially developed privately before being shared on cvs.php.net and becoming the de facto standard PHP testing framework. - Event-sourced application testing using given/when/then patterns creates readable, maintainable tests that generate visual documentation aligned with domain modeling techniques like event storming, providing living maps of system behavior. ## 📰 Newsletter **Testing Revolution: Sebastian Bergmann Shares PHPUnit's Evolution and Event-Sourced Testing Innovations** PHPUnit creator Sebastian Bergmann joined our podcast to discuss the framework's 26-year evolution and groundbreaking approaches to testing event-driven applications. His journey from Amiga programming to creating PHP's most essential testing tool showcases the power of solving personal development needs. The latest PHPUnit 13 release brings eight new array comparison assertions and improved mock object parameter matchers, making testing more flexible and maintainable. Perhaps most exciting is Sebastian's work on visual documentation generation from event-sourced tests using given/when/then patterns. Key takeaway: Testing isn't just about verification—it's about creating living documentation that maps your application's behavior and supports domain-driven design practices. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Present event-sourced testing patterns at conferences, create PHPUnit workshops - Education: Develop curricula around given/when/then testing patterns, board game training modules - Developer experience: Document PHPUnit event system for extension development - Developer marketing: Promote PHPUnit 13 features, visual documentation capabilities - Community management: Foster testing best practices discussions, mentorship programs #### Community - Maintainers: Share testing governance templates, code coverage improvement strategies - Contributors: Create PHPUnit extension examples, testing pattern documentation - Sponsors: Support testing infrastructure improvements, conference speaking opportunities - Ecosystem: Coordinate testing standards across PHP frameworks #### WordPress - Core: Implement event-driven testing patterns for WordPress core development - Core Performance: Use visual documentation for performance testing workflows - Community: Develop testing workshops for WordCamps, create testing mentorship programs - Training: Include advanced PHPUnit techniques in developer courses - Documentation: Add testing best practices to WordPress developer documentation - Plugins: Establish testing standards for plugin directory submissions ## 🧪 Hypotheses - Event-sourced testing with visual documentation generation reduces debugging time and improves developer onboarding - Board game domains provide more engaging and memorable technical training than generic examples - PHPUnit's event system enables unprecedented extensibility for testing workflows and documentation - Given/when/then testing patterns bridge the gap between business requirements and technical implementation ### 📊 Methodology - Study design: Compare debugging time and code comprehension between traditional tests and visual event documentation - Data sources: Developer survey data on training effectiveness using domain-specific vs generic examples - Experiments: A/B test PHPUnit extensions for documentation generation and developer productivity metrics ### ❓ Questions - How can WordPress core development adopt event-sourced testing patterns for complex feature development? - What testing documentation standards would most benefit the PHP ecosystem? - How might visual test documentation integration with GitHub improve code review processes? ### 🔮 Future Research - Integration patterns between PHPUnit visual documentation and existing developer workflows - Comparative effectiveness of domain-driven training approaches across different technical concepts - Standardization opportunities for event-sourced testing patterns across PHP frameworks ### 💡 Implications - Practice: Testing becomes documentation generation tool, shifting from verification to system mapping - Policy: Testing standards may need updating to accommodate visual documentation requirements - Education: Domain-specific examples (board games) may significantly improve technical training effectiveness - Funding: Investment in testing infrastructure improvements could yield substantial developer productivity gains ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Board game examples, event storming sticky note visualizations - Improve: PHPUnit architecture diagrams, test flow visualizations, code coverage heat maps #### 🔊 Aural learners - Present: Podcast format with detailed explanations - Improve: Audio examples of test execution, narrated code walkthroughs #### 🗣️ Verbal learners - Present: Clear analogies (bank account events, board game rules) - Improve: Glossary of testing terminology, event-sourcing vocabulary #### 🧩 Kinesthetic learners - Present: Board game training exercises, hands-on coding examples - Improve: Interactive PHPUnit playground, step-by-step testing tutorials #### 🧠 Logical learners - Present: Sequential development timeline, cause-effect relationships in testing - Improve: Testing decision trees, architectural flow charts #### 🧑‍🤝‍🧑 Social learners - Present: Discord community discussions, conference presentations - Improve: Testing mentorship programs, collaborative debugging sessions #### 🧘‍♀️ Solitary learners - Present: Individual exploration of PHPUnit features - Improve: Self-assessment testing quizzes, personal project templates #### 🌿 Naturalistic learners - Present: Evolution of testing frameworks over time - Improve: Testing ecosystem relationships, framework lifecycle comparisons ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear headings in code examples, descriptive code comments - Improve: Alt text for visual documentation outputs, ARIA labels for test result displays #### Keyboard navigation - Present: Command-line focus throughout examples - Improve: Keyboard shortcuts for PHPUnit IDE integrations #### Contrast and readability - Present: High contrast in terminal output examples - Improve: Customizable color schemes for test result visualization #### Text resizing and reflow - Present: Plain text code examples scale well - Improve: Responsive visual documentation layouts #### Media and captions - Present: Podcast transcript available - Improve: Captioned code demonstration videos #### Forms and interactions - Present: Clear CLI command structure - Improve: Accessible web interfaces for PHPUnit reporting tools ### 🌍 DEIB Assessment #### Cultural breadth - Present: International perspective (German/UK experiences) - Improve: Examples from diverse cultural contexts, global testing practices #### Inclusive language - Present: Technical explanations avoid jargon where possible - Improve: Define domain-specific terminology consistently #### Neurodiversity support - Present: Structured conversation format, clear topic transitions - Improve: Visual organizers for complex testing concepts #### Representation - Present: Multiple speakers from different backgrounds - Improve: Diverse examples beyond gaming references #### Psychological safety - Present: Respectful discussion of learning challenges - Improve: Explicit encouragement for testing beginners ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear progression from personal need to framework creation - Inductive strength: Multiple examples support broader testing principles - Causal reasoning: Well-established links between testing approach and outcomes - Analogical strength: Effective use of board game and banking analogies #### Fallacies - Appeal to authority: Minimal - Sebastian's expertise is relevant and well-established - False dichotomy: None identified - multiple testing approaches acknowledged #### Tone of voice - Overall tone: Collaborative and educational, with appropriate technical depth and personal anecdotes ### 🛡️ DARVO Analysis - Deny: No problematic denials identified - Attack: No attacks on individuals or groups - Reverse victim/offender: Not applicable to technical content - Emotional cues and rhetoric: Positive, encouraging tone throughout ## 🎯 Conclusion Sebastian Bergmann's conversation reveals how personal development needs can drive ecosystem-wide innovation. PHPUnit's evolution from solving individual testing challenges to enabling visual --- ## Full Transcript [00:06] Hey, [00:21] hey, hey. [00:25] Heat. Heat. N. [00:43] Hey, [01:01] hey, hey. [01:03] Heat. Heat. [01:27] Heat. Heat. [02:00] Heat. Heat. [02:25] Heat. Heat. [02:57] Do you lie awake at night? Are you [03:01] afraid to turn out the lights? Is there [03:03] something you're scared of? [03:08] What's there out in the dark? Make sure [03:11] to keep all your windows locked. Do you [03:14] do you surrender? [03:17] You try to try to stay away these walls. [03:21] You can't escape. [03:23] Here's one for the lonely hearts. For [03:26] the ones that fear the dark, you better [03:28] run out. Run out of here. Bet you can't [03:31] look the other way. Here's one for the [03:35] broken road. That's the only one you [03:38] know. You better run out. Run out. Truth [03:40] or dare. Get me out. Take me anywhere [03:43] but here. [03:48] Anywhere but here [03:56] to come. Waiting for [04:09] Do you lie awake at night? Are you [04:12] afraid to turn out the lights? Is there [04:15] something you're scared of? [04:19] What's there in the dark? Make sure to [04:23] keep all your windows. [04:51] Hello and welcome to PHP Alive and [04:54] Kicking. Uh, this is episode and I don't [04:57] know what the number is now. [04:59] >> 25. [05:00] >> 25. Thank you. There you go. Great [05:02] start. [05:03] I'm Mike. My co-host is Chris. [05:07] >> Hello. [05:08] >> Uh, this podcast is brought to you by [05:10] PHP Architect and made made better by [05:14] our partners at PHP score. Uh, more [05:17] about them later if I can put my teeth [05:19] in and I can speak. I do have a side [05:22] defense. I'm just getting over a really [05:24] nasty cold. So, I'm still bunged up and [05:27] still can't talk. Apparently, [05:30] we explore the de developments in PHP [05:33] and what it's like to earn a living in [05:34] PHP today. Uh, this is a live recording. [05:39] So, if you are in our Discord channel, [05:42] which we will bring up now. [05:45] >> Hold on. [05:46] >> There you go. If you're in our Discord [05:48] channel, you can join in. uh post [05:51] questions for our guests. Um the the uh [05:55] Discord isn't just for uh when we're on [05:57] live. You can hang out in there all week [05:59] long. There's all sorts of [06:00] conversations. There's quite an [06:01] interesting conversation just before we [06:03] we went uh live uh going on in there. So [06:07] do join us. There's all sorts of cool [06:09] people uh in there. And [06:12] that is the Discord channel. Sorry, I'm [06:15] losing my complete train of thought [06:17] here. Um YouTube, if you're watching [06:18] this on YouTube, please like and [06:20] subscribe. Um uh we also run a monthly [06:24] magazine for all around uh PHP and other [06:28] tech. Uh we do have a code for all our [06:31] listeners to get the first three months [06:35] three of a year's digital subscription [06:38] and that is a live three. So, head over [06:40] to our website and use that code uh to [06:43] to get those first three um episodes for [06:47] free. Uh alongside our development work [06:50] and our magazine, we also run PHP Tech [06:54] every year in it's in Chicago this year. [06:56] Not long now. [06:58] >> It's uh it's it's catching up. It's it's [07:00] not far off now. Um so, yeah, that [07:03] that's that's going to be happening. [07:04] Alongside PHP Tech, we've actually [07:06] running for the first time JStech, which [07:10] is a uh conference dedicated to [07:14] JavaScript that'll be running alongside [07:16] PHP tech in the same hotel rooms [07:19] adjacent. So yes, we are mixing PHP [07:21] developers with JavaScript developers. [07:24] What could go wrong? [07:25] >> Everything. Um not only that, we we are [07:28] also if you subscribe to one, you get to [07:30] go to the other one too. [07:32] >> That is true. That is true. We're not [07:34] holding tickets at the door. [07:37] >> Uh we've also also got a swag store [07:40] which you can head over. There's pretty [07:42] some cool stuff over there. T-shirts, [07:45] caps, and cups and things. That is [07:47] store.phparch.com. [07:50] Uh so head over and check out what we've [07:52] we've got over over there for [07:54] >> So if you put in the order for the [07:56] t-shirt that we won yet. [07:57] >> Nope. [07:58] >> Nor [08:00] still haven't done yet. One day, one day [08:03] I'll remember to do it. The the only [08:05] time I remember about it is when we're [08:06] on the show and I can't really order it [08:08] while we're on the show. Um so yeah, um [08:11] we will do soon. Um right, enough of us [08:13] rambling because they don't these people [08:15] don't really come to watch us ramble on [08:17] about rubbish, do they? [08:20] >> No. [08:20] >> No. Um we bumped into someone. We went [08:23] to uh uh PHP UK a couple of weeks ago. [08:27] Had an absolute blast. um met loads of [08:29] people and uh today's guest is one of [08:32] the speakers who has kindly agreed to [08:35] come on and somehow navigate us through [08:38] all the nonsense that we get up to on [08:39] this show. We might actually have a [08:41] steady ship this time. [08:43] >> I mean, it's possible. [08:46] >> So, who have we who have we got? [08:49] >> So, we have the wonderful Sebastian [08:53] Bergman. Hello. [08:55] >> Hello, Sebastian. [08:56] >> Hello. [08:59] Now, now I have a question. Why have the [09:01] names come back? [09:04] Hang on. [09:06] You see that is because whoever develops [09:09] this app that we use to do this live [09:12] stream and recording they hear heard us [09:15] before we went live [09:19] >> their products mentioning that they [09:21] probably don't test their product [09:23] because of all the bugs that that we [09:25] noticed just in the last 10 15 minutes. [09:29] >> Yep. and be they listened in on us [09:32] violating our privacy and went along and [09:35] fixed those bugs. [09:37] >> There we go. [09:38] >> There's one case [09:40] possible explanation that makes sense. [09:44] >> So, it's probably one that doesn't make [09:46] sense, but [09:48] >> anything's possible. [09:52] >> Oh, only we knew someone that could that [09:54] knows a lot about [09:56] >> Yeah. [09:57] >> Yeah. Let me know if you find one. I've [09:58] I've been trying to figure out this [10:00] testing thing for 26 27 years now. [10:04] >> I mean, there's this one thing I use [10:06] called PHP unit. Seems pretty good. It's [10:09] >> pretty stable, good at testing. [10:13] >> So, for anybody that doesn't know, [10:15] Sebastian actually wrote PHPUnit. [10:19] So, Sebastian, we always start with the [10:21] same question to everybody we bring on [10:23] for the first time. [10:25] >> How did you get into PHP? [10:28] How did I get into PHP? Um, [10:32] yes, that was a [10:35] that was a long time ago. Let's start [10:37] there. Um, that was in 1998. [10:44] Um, and to give you a perspective, where [10:47] was little Sebastian [10:50] in his life at that time? Um, it was the [10:54] time for me between I had just finished [10:57] my military replacement service, the [11:00] so-called civil service in in Germany. [11:02] Back then, we still had the draft. So [11:05] you either had to go to the military um [11:07] for about a year and as an alternative [11:10] for a little bit longer do civil [11:12] replacement service and I worked at a [11:14] hospital. And after that concluded and [11:18] university started for me, I had a [11:22] couple of months of time and I decided [11:24] to do an internship at a computer [11:27] science research institute. [11:32] and just because I thought that this [11:34] would be a brilliant use of the time and [11:37] I would could learn something and [11:38] whatever. But I arrived there on on the [11:41] first day the person responsible for me [11:44] went on a three month research trip [11:47] somewhere else and I was on my own [11:51] and had basically nothing to do. So [11:55] fortunate timing that I was contacted [11:58] then by someone I knew from the Omega [12:04] demo scene. So I grew up learning [12:08] programming on on the Omega. [12:10] Got an Omega 500 in 1990 and an Omega [12:13] 1200 not so much later basically when [12:16] that machine came out. And I was always [12:19] fascinated by the intros, the cracks and [12:22] the demos that people did on those um [12:25] machines. And I wanted to be able to do [12:27] that myself. So I dabbled a bit in that [12:30] and got to know a couple of people who [12:33] were a lot better at that than me. So I [12:38] quickly stopped doing that. But what I [12:42] found out that I was really good at was [12:45] writing software [12:47] as extensions for mailbox software, [12:50] bulletin board system software that was [12:52] used by all the I mean it's so long in [12:57] the past that I'm allowed to that I'm [12:59] comfortable enough saying that but but [13:01] by all the bulletin boards where the [13:03] amigga cracked games were traded [13:06] basically all of them were using the [13:08] same bulletin board system software And [13:10] most of them used software that I wrote [13:12] to extend that. And then at that time [13:15] when I was doing the internship and I [13:17] was bored. Um someone contacted me and [13:20] said um hey I used to be a graphics [13:22] artist on the amigga and you did some [13:24] coding and to me as someone who is not [13:28] into programming all programming is the [13:30] same and I'm now doing internet [13:34] whatever that may mean right I'm doing [13:36] internet. So what he meant was he was [13:38] doing front page and Photoshop and doing [13:42] websites um for his clients and that was [13:45] good enough for a while like the skills [13:48] that he had as an artist for doing that [13:51] but then came the moment when he needed [13:54] something that happened with business [13:55] logic on the server and he was not the [13:58] right person for that. So he reached out [14:00] to me because for him that is exactly [14:04] the same thing as doing extensions for [14:08] mailbox software on the Omega because [14:09] one thing is programming, the other [14:11] thing is programming, right? [14:14] And [14:16] I had no idea how to do serverside [14:19] programming. So I asked what programming [14:22] languages are are there for that? and he [14:25] said, "Well, you have the choice between [14:26] Pearl and PHP on the server." So, I [14:30] tried my hands at Pearl for one or two [14:33] hours and then stopped doing that [14:36] because I I was not compatible with that [14:39] language. [14:41] I forgot the details but [14:44] I tried PHP and was able to learn enough [14:49] PHP in a weekend to build the [14:52] application that he needed built for his [14:55] customer [14:57] and then I filed that away in my memory [15:01] as okay this was nice interesting so [15:03] this is how serverside programming works [15:06] maybe maybe that will become relevant um [15:09] data [15:11] and I kept doing things like that and [15:14] then subscribed to the mailing list, [15:16] started asking questions, eventually [15:18] started answering questions, [15:21] started contributing to the PHP [15:23] documentation, translating documentation [15:25] from English to German, fixing small [15:27] issues in the English documentation, [15:29] found at some point a bug in PHP itself [15:33] or something that annoyed me enough to [15:36] look into um how PHP is implemented and [15:40] I found oh this is implemented in C. I [15:43] know C. So now I need to figure out how [15:46] C and the language ecosystem around C, [15:49] build systems, etc. work on Linux and [15:53] fix the bug. [15:57] And that was around the time that [16:00] development started in earnest on PHP 5. [16:07] And I by then I was at university and um [16:12] learned about object-oriented [16:13] programming and was part of a research [16:18] group on on programming language design [16:21] and started discussing ideas that I got [16:24] with some people that were working more [16:28] deeply on on PHP's core than I ever did [16:32] and gave them ideas, discussed ideas and [16:35] contributed to [16:38] uh design of things like reflection API [16:40] uh and other related things that I [16:44] needed to implement PHP unit in the [16:47] proper way. [16:51] So you started on the second system I [16:55] had which was the Omega 1200. The first [16:58] one I had was the ZX Spectrum 48K. [17:02] >> Mhm. and me and my dad literally sat in [17:04] the kitchen and solded that one [17:05] together. That that's how old computing [17:07] was for me. And it turns out that I [17:10] think 30 years ago in 1995 we were at [17:14] the same conference to do with Omega [17:18] >> could be [17:21] which I mean that that's small world. [17:24] Two people from two different countries [17:26] start in the same way and end up in the [17:28] same language. [17:31] So [17:32] >> there I mean I I remember being um a [17:36] teenager and I remember having the [17:37] AmIGGA as a teenager and right my first [17:40] experience of coding. Now I can't [17:42] remember if it was on the MIG whether it [17:44] was on something at school. Um but I I [17:47] wrote a a really simple math test for [17:50] the amigga which had about five [17:52] questions. It just sort of pinged if [17:54] you're right or g or made another sound [17:56] if you're wrong and then showed the [17:58] correct answer. Um, but for me [18:01] unfortunately I didn't realize I don't I [18:05] don't really remember but I because I'm [18:07] dyslexic a lot of people were telling me [18:08] that I need to go into sort of a more of [18:10] a labor type of job um building work and [18:14] things like that. So I left computers [18:18] behind but I've come back to them [18:21] eventually and again yeah found PHP and [18:24] um bit like yourself I I tried PHP and [18:28] realized it was just really easy to [18:30] learn quite quickly. [18:32] >> Yeah heard [18:33] >> Sarah in Discord we all know Sarah says [18:36] Sebastian on Pearl. I was not compatible [18:39] with that language. I mean, honestly, I [18:42] don't think many people are these days [18:44] compatible with Pearl. It's it's one of [18:46] those languages that I just don't get. [18:49] It just doesn't sit in the way that PHP [18:53] does and [18:54] >> JavaScript is totally different [18:56] paradigm. [19:00] So that that path sort of led you to PHP [19:04] unit and writing PHP unit. [19:07] Yeah, because I because I I started [19:10] writing more and more software in PHP [19:13] and soon realized I want to be able to [19:22] funny thought test the software that I [19:25] built and and ensure that it actually [19:27] does what it is supposed to be doing [19:30] because I was very fortunate to have a [19:32] professor at university [19:35] um who really early on because he was um [19:40] he he knew Eric Gama and Kent Beck and [19:42] others who were who created JUnit like [19:47] the two of them and made it popular and [19:52] we at university started really early on [19:55] using that and I I found it in this an [19:58] interesting concept of [20:02] it's part of my responsibility as a [20:04] developer Not only to write the software [20:07] that actually runs whatever it is [20:10] supposed to run, but also write the [20:14] tests that verify that the software does [20:16] what it is supposed to be doing and not [20:18] delegate that um to to somebody else. [20:22] And I found that fascinating. And for I [20:26] I I I searched for [20:30] a solution for that in PHP because to me [20:32] by that point it was clear like I PHP is [20:35] a language that I enjoy working with uh [20:39] and that is very well suited for the [20:42] kind of things that I needed to do and [20:45] wanted to uh to do. So I wanted to have [20:47] a test framework like JUnit for that. [20:50] And clearly I cannot be the first person [20:54] on the planet wanting that. So somebody [20:57] must have already built that, right? Um [21:00] so I started searching for that. [21:03] And [21:05] this was a time when version control or [21:10] the predominant version control system [21:12] was CVS [21:15] and the opensource code hosting platform [21:19] was SourceForge. [21:21] Before it was a place for for malware [21:25] and ads and whatever it has become since [21:28] then. [21:29] So on source forge there was a project [21:32] named PHPUnit [21:35] and for a couple of minutes I was was [21:37] happy yes somebody has built that and [21:39] then I tried using it and I could not [21:43] get it to work. [21:45] I mean it's still there because projects [21:48] are never deleted on SourceForge, right? [21:50] But um I I I tried contacting the author [21:54] but never got a reply and then [21:56] eventually I started [21:58] building what later became PHPUnit. But [22:02] for about a year, I did not want to [22:07] share that with the world because I was [22:08] still hoping that somebody else who is [22:11] much better [22:13] qualified than me to do that to create a [22:16] project like that. And then at some time [22:20] um it it became [22:24] just too painful to not have the thing [22:27] that I was using in my project as a real [22:29] project that that is out there somewhere [22:32] and others can use that can provide [22:34] feedback and benefit from that. That's [22:36] when [22:38] because somebody gave me right access to [22:41] cvs.php.net [22:43] and allowed me to create new projects. [22:45] So I just put it there because I [22:47] couldn't put it on source forge. [22:51] >> So So was that Sarah? Can we blame Sarah [22:53] for that? [22:55] >> You know, you can blame Sarah for a lot [22:57] of things, but I don't think that she [23:00] used to blame for that. [23:04] >> I mean, I'm only blaming her because [23:06] she's talking about kids do weird [ __ ] [23:08] and back when we were doing Pearl. And [23:12] uh John our boss is also talking and [23:14] there about how he started with web [23:16] development with Pearl and he says I [23:19] guess I was compatible and then points [23:21] out the old database access. You didn't [23:23] have field names back then. You just had [23:25] to know that data zero was the ID. [23:28] Yes, [23:30] I I've worked on projects like that. [23:37] Well, on that note, I'm think we'll just [23:39] hear from our our sponsors and have a a [23:41] quick break. So, we'll be back in just a [23:44] moment. [23:48] Thank you to our partners at [23:49] phpscore.com. [23:51] Every app builds up technical debt over [23:53] time. It's the price we pay for shipping [23:55] new features and moving fast. When we [23:58] build up too much of it, though, it can [24:00] start to impact how we work. Team [24:02] velocity suffers, bugs become more [24:04] frequent and take longer to fix, and [24:06] everyone starts to get a little [24:07] frustrated. The key to managing debt is [24:10] to measure it. A credit score can help [24:13] you understand how well you're managing [24:14] your financial debt. And now there's a [24:17] credit score for your technical debt. Go [24:19] to phpsscore.com to get a free technical [24:22] debt score and monitoring for all of [24:24] your PHP applications today. [24:30] >> Thank you. PHP score. [24:34] >> I think this was quite [24:36] >> Yes. [24:38] Yes. I I also want the answer to the [24:41] other one. [24:45] >> Yeah, I think so too. I I don't predate [24:48] her as in the meaning of being on the [24:52] face of this planet but I think I [24:57] as far as the PHP project is concerned I [25:00] think I was involved before that. Yes, [25:02] for whatever that that matters I I I [25:05] don't think it does. [25:11] So Sebastian to PHP UK you were talking [25:14] about a concept that to me was literally [25:17] mind-blowing the idea of unit testing [25:21] event sourced or eventtormed [25:24] applications [25:26] which I went on and implicated on a app [25:29] that I'm building and loved it. [25:32] >> Firstly you've got an article about that [25:35] haven't you? [25:37] >> I didn't catch the last part. You've got [25:39] an article about that on your blog, [25:41] haven't you? [25:42] >> Yes, I have an article about that on my [25:44] blog. So that that's something that I [25:47] try to do for a while now that when I [25:49] give a presentation for the first time [25:51] like I did now with um from events to [25:55] insights at the PHP UK conference that I [25:58] have an article ready on my blog when I [26:03] give the presentation for the first time [26:04] so that I can um point uh people to that [26:09] article. Sorry Sarah, you somehow asked [26:12] for that. [26:17] Um, yes, [26:21] >> I'm currently looking for that article. [26:24] I shall find it in a moment and make [26:25] sure it goes out of the show notes. um [26:28] the the concept that you were presenting [26:30] of the idea of being able to do given [26:33] when then when then [26:34] >> directly in PHP unit tests [26:39] explain the mechanism behind that and [26:42] how that's actually coming from PHP unit [26:44] because I think that was the important [26:46] part drawing it from the from the [26:48] additional data. [26:51] So I'd like to take a step back for a [26:56] moment and [26:58] very briefly introduce the concept of or [27:01] talk about the concept of eventdriven or [27:04] event sourced systems. [27:06] And that is a way of building systems [27:11] where the where the source of truth is [27:14] not [27:15] a typical relational data model. a [27:19] typical CRUD data structure that you [27:22] have that only represents the current [27:24] state of your world and you do not know [27:27] how you got to the current state, but [27:30] instead you keep a record of everything [27:33] that is relevant to your domain as it [27:38] happens as an immutable event. [27:42] And the hello world example of that is [27:45] that of a bank account which is at some [27:47] point in time opened and then [27:50] transactions are happening. Money is [27:52] deposited, money is transferred, money [27:54] is withdrawn and for every thing that [27:58] happens which is an event. you record [28:00] that event and then on the one hand you [28:05] have uh an audit trail out of the box [28:08] and for free because you can just look [28:10] at this event stream this record of of [28:12] events that have happened and see what [28:15] has happened when and why. [28:18] And you can reconstruct the current [28:21] state of a bank account for example just [28:25] by looking at those events [28:28] and not only show this is the current [28:30] balance but this is how we got to the [28:32] current balance. [28:36] And now like and I I came across that [28:41] way of building [28:43] software over 10 years ago or over 15 [28:46] years ago by now like like a long time [28:49] ago. And when I first came across that [28:56] I I realized hey this is this really [28:59] helps to think about a system and it [29:01] this is very elegant and it helps solve [29:04] a lot of problems [29:09] but in my mind immediately I had this [29:12] big problem but how in the world am I [29:15] going to test a system like that because [29:17] this must be a lot more complicated and [29:20] complex and tedious and cumbersome and [29:24] insert your favorite adjective here [29:28] until I realized that actually the [29:30] opposite is the truth because it makes [29:35] at least for me [29:37] testing [29:39] a lot easier [29:43] because instead of oh how do I prepare [29:47] my crutch [29:49] style [29:50] database, how do I bring it into a state [29:53] that I can run my test and how do I [29:55] clean it up afterwards and how do I [29:58] figure out by looking at the database [30:01] whether or not what I want to happen has [30:03] happened. I can express my intent in my [30:08] test [30:10] in a readable, maintainable and straight [30:13] straightforward [30:15] manner that is aligned with the rest of [30:18] my architecture and design of my [30:20] application. [30:22] And this is where the given when then [30:26] metaphor comes into play that that that [30:28] you mentioned earlier. I can just say [30:31] okay in the context of this test for [30:33] whatever it is that that I currently [30:34] want to test given that these [30:38] events have happened in the past when I [30:42] perform this command when I execute this [30:45] action whatever you want to call it then [30:48] I expect that these other events have [30:51] now been recorded [30:54] and then you can abstract that away [30:56] extend the test framework in this case, [31:00] PHP unit, adapt it to [31:04] your project and to your framework or [31:08] whatever you want to call it, how you [31:11] interact with events [31:13] and have [31:16] the language from your tests where you [31:18] call the three methods given when then [31:22] translate that [31:25] into the relevant code that needs to be [31:27] run underneath the test to make the test [31:30] possible. [31:32] And depending on the context and scope [31:36] of your test, like for example, if you [31:39] are in a unit test, you do not want to [31:42] use a real event store. You do not want [31:44] to use a real persistence layer. The [31:47] same given when then calls are there [31:50] translated into the creation of test [31:53] stops and mock objects to simulate the [31:56] event system. [31:58] But you can reuse the same test code [32:03] in a different context and have the [32:07] given when then calls there be [32:10] translated into for an integration test [32:14] or an end to end test into code that [32:18] creates a real event store uses the real [32:21] event system and and and things like [32:23] that. [32:26] >> Yeah. and that that whole process does [32:30] make the tests literally the contract [32:33] that they're supposed to be in the first [32:35] place. [32:38] Um, we currently have Derek in the [32:41] comments asking when he's coming on and [32:42] we're trying to arrange a podcast with [32:44] Derek at the same time as talking to Sp. [32:46] >> Yeah, the chat is a bit confusing. I try [32:49] to focus on your faces but then I see [32:52] the chat messages come up. that that is [32:56] and I I decree that we that we use [33:01] Sarah's suggestion and um make [33:05] uh and call the call it the BS time the [33:08] before Sarah time. [33:10] >> Yep. [33:11] >> Just for for fun. [33:15] >> Yeah. [33:16] >> Why not? Why not? [33:22] Uh Sarah is definitely not available [33:24] next Tuesday. Um [33:27] I mean we [33:27] >> That's right. S Sarah, we weren't asking [33:29] you to come on the show again. We've had [33:31] you twice. [33:31] >> No, [33:33] we haven't recovered from the last [33:34] chaos. Um [33:36] >> so this time system also translates [33:40] uh to this podcast as a BS before Sarah [33:44] came on the podcast and after Sarah came [33:46] on the podcast. [33:46] >> Well, there is before because she was [33:49] our first guest. [33:50] >> Okay. [33:51] There is technically one episode before [33:53] Sarah, but that's just me and Mike [33:55] giving our stories [33:59] coming of Sarah on the podcast and after [34:02] she [34:03] >> Yeah. Yeah. She's she's she she was the [34:05] first one of this year. [34:06] >> Okay. [34:06] >> Yes. [34:07] >> She she brought us [34:13] So [34:16] Sarah says we read [34:21] Um, [34:23] >> yeah. Well, [34:23] >> so yes, the [34:25] >> you're a big you can do it. [34:28] >> I mean, we did introduce her as the [34:29] loudest voice in PHP. Um, so [34:34] the way that those tests read once [34:36] you've established that, it literally [34:38] gives you the contract of what your what [34:41] your application goes on. [34:44] Um, and by being able to write like [34:48] that, it makes it so easy to then see [34:50] from the PHP doc output exactly what [34:53] went on. And that that concept makes it [34:58] so easy to then just pass that to [35:00] customers, the next person that needs to [35:02] see it and go, [35:03] >> is this what we intended? [35:07] >> The short answer to that would be yes. [35:10] The slightly longer answer would be it [35:14] was a journey. [35:16] >> So my journey started with I want to be [35:20] able to have a have test code that is [35:26] readable, understandable to the people [35:29] working on the tests on the code of such [35:32] a system. [35:36] And then [35:40] the more I was getting into collabor [35:43] collaborative modeling techniques like [35:46] event storming um and things like that, [35:50] I want to get a visual documentation out [35:55] of running the tests that goes full [35:59] circles um to if you will the input of [36:04] the the actual writing of code which is [36:09] a lot of sticky notes on the wall [36:11] >> that are colorcoded and then you have [36:14] orange stickies which are events and [36:16] then you have diff green stickies for [36:18] for read models and things like that and [36:22] I wanted to get in that visual language [36:26] documentation that is generated from [36:31] running the tests. So [36:35] this is what I built as an extension for [36:38] PHP unit that is project specific for [36:40] the example project that I used in my [36:44] presentation and that that I use in the [36:46] article. So this is not something that [36:50] is a generic [36:53] extension for PHPUnit that you can just [36:55] install and and use in your project. [36:59] Um [37:01] but it shows the idea and I I think it's [37:04] easy to adapt what I have published um [37:07] in this example project two specific [37:10] projects. I think it's harder [37:15] to turn that into something that is [37:18] generic enough that it would be useful [37:22] to distribute as an open source project. [37:26] Right. And [37:28] So the idea is I can do uh a [37:32] collaborative modeling session like [37:34] eventtorming get a lot of stickies get [37:37] an shared understanding of all the [37:40] stakeholders of what is supposed to be [37:42] built. [37:44] Use that as input for the development. [37:48] write my tests in such a fashion that I [37:50] get visual documentation that uses that [37:52] visual language as output from running [37:55] the tests that I can then compare to my [38:01] photos of um the event storming wall to [38:05] figure out did I actually build what I [38:07] was supposed to be building like that [38:09] that is one way that can be used but it [38:11] can also be used to quickly show someone [38:15] hey for this command these These are the [38:18] tests that I have. Um this is the visual [38:20] documentation. Does this match um what [38:22] what you have in mind? Yes or no? Where [38:25] do we need to iterate? [38:28] And of course, if you collect all of [38:30] that data from all the tests that you [38:34] run, [38:36] you get um you get a map of your [38:40] software system through the lens of [38:43] events and you see these are all the [38:46] events in my system. [38:48] This event is emitted here and it is [38:52] consumed here, here and here. And this [38:56] is a really helpful [39:00] source of information for developers [39:02] that want to that that need to work on [39:04] the software and need to change [39:05] something because this gives them the [39:07] canonical source of truth which parts of [39:12] the system are affected when I make a [39:15] change over here [39:18] like I change how that event is emitted [39:21] or how that event looks like or [39:24] whatever. [39:25] which other parts of the system do I [39:27] need to keep in mind when I make a [39:29] change there? And that is really [39:31] helpful. [39:33] >> Yeah. And that that map that it produces [39:36] is literally by the time you've done the [39:38] whole app. So easy to refer back to and [39:42] just go there. That's what it is. And it [39:45] just flows straight through. I mean, [39:47] when I when I put it in on the app that [39:48] I've been working on it, at the moment, [39:50] it's going only got about 50 events, but [39:53] those 50 events are interlaced around [39:56] like 20 or 30 different places. And [40:00] seeing that map also gave me the [40:02] opportunity to go, do you know what? [40:04] This is doing more than it should for [40:05] each event. Let's make two events out of [40:07] it. And you could see an easier pathway. [40:11] And just by having that visual output [40:13] made it so easy to understand the whole [40:15] pro process [40:17] and the fact that you can even get that [40:20] at a PHP unit is impressive [40:24] and I I don't know of another framework [40:27] that can do that. I know there probably [40:29] is but I don't know of one in other [40:31] languages that you can actually use that [40:32] information to produce that. I would say [40:35] that this is possible in every [40:39] test framework because every test [40:42] framework that I know no matter which [40:44] programming language it is for you write [40:47] the tests in that language [40:51] and you can do anything you want in that [40:53] code that you have in your tests. Now [40:56] whether or not that is clean and elegant [41:00] and and actually usable and maintainable [41:03] that may be a different story. [41:05] But I what we talk about here right now [41:10] is one of the things that I had in mind [41:13] when we [41:15] um implemented the event system for [41:18] PHPUnit itself which we introduced in [41:20] PHPUnit 10. [41:22] >> Mhm. which um completely changed all the [41:27] code inside of PHPUnit that is [41:32] responsible for output. Be it output [41:35] that you see on the console when PHPUnit [41:38] is running to report progress to pro uh [41:40] report results, report failures and so [41:44] on or be it output in the form of log [41:48] files. [41:50] All of that is now based on event system [41:55] and the event system in PHPUnit that is [41:59] read only. So nothing is controlled [42:03] through the events. [42:06] PHPUnit just emits an event every for [42:09] everything that is relevant in the [42:11] context of running tests. There are [42:14] about [42:16] I have no idea how many events there [42:18] are. dozens like for anything that is [42:20] meaningful. The execution of a test [42:22] started the execution of a test stopped. [42:24] Exe PHPUnit as a whole started. PHPUnit [42:27] as a whole has stopped. Um a test stop [42:30] was created. A mock object was created. [42:34] Whatever you name it, we have an event [42:36] for it. [42:38] Um and PHPUnit itself [42:42] subscribes to the events that are [42:45] relevant to create for instance the [42:47] output on the console. [42:50] But you can write extensions for PHP [42:54] unit subscribe to these events and if [42:58] you want completely change [43:02] the output that you get from PHPUnit. [43:05] This is for example what [43:09] extensions for PHPUnit like pest do. [43:13] >> Mhm. [43:14] >> Yeah. Pest is an extension for the [43:16] phpunit testr runner among other things. [43:19] It also extends PHP unit in other ways. [43:22] But part of pest is a piece of code that [43:27] subscribes to events to produce its [43:31] output because they want different [43:33] output than what PHPUnit produces out of [43:36] the box. And such an extension can tell [43:38] PHPUnit, [43:41] I take over control of the output. [43:44] Please do not produce any output. only I [43:47] will produce output [43:50] and that's what they do. [43:53] Alternatively, and this is what the [43:55] extension does that I showed in my [43:57] presentation in London is that you can [44:00] write an extension that subscribes to [44:02] some events and does not produce output [44:06] by printing to the console but by [44:09] generating a file in a directory. [44:12] Mhm. [44:13] >> In the case of that extension, that is a [44:16] bunch of PDF files [44:18] with the visual documentation. [44:20] >> Yeah. [44:24] >> So when I uh when I implemented it, I [44:27] slightly changed the extension that you [44:29] were doing so that it was outputting [44:30] mermaid directly as MDs [44:33] >> because then they're commitable and you [44:36] can see them in GitHub. But the [44:38] principle just gives you so many avenues [44:41] to go from there. And uh I've been [44:43] toying with the idea of how could you [44:45] take the concept to non-event sourced [44:48] apps and looking at how does that work? [44:51] Could you use PHP units testing to give [44:53] you a map of an application that isn't [44:56] event sourced? And the answer appears to [44:59] be yes. It's it's a bit messy at the [45:02] moment to try and get it to work because [45:04] you're reliant on good clean [45:06] segregation, [45:08] >> but in theory it's possible. And it's [45:11] it's quite an interesting concept to [45:12] look at going from just text on a screen [45:15] that says yes or no, it passed [45:18] >> to a documentation that's alive that [45:21] tells you how the app performs and how [45:25] does it do its job. And it's it's almost [45:29] like testing is a good thing. It's [45:32] >> Yeah, we might be on to something there. [45:34] >> Mhm. [45:36] >> But before we go to the next question, I [45:37] just want to say anyone that is uh [45:39] watching live, you can pop into Discord [45:41] and put any questions to Sebastian. Um [45:44] I'm sure be happy to answer anything [45:46] that you put put in there. [45:50] I mean, I'm sort sort of half half [45:51] expecting Nuno to ask ask another [45:53] extension for for pest in a minute. [45:58] >> Nuno is in our Discord and does [45:59] occasionally watch the podcast. [46:01] >> Mhm. [46:04] >> Um so, um I noted that uh um PHPUnit [46:08] 13's just recently released. [46:11] >> Yes. [46:12] >> Um back in February, was it? I've noted [46:14] down. [46:15] >> First Friday of February. [46:17] >> Yeah. And so, so what what's new? what's [46:19] what's being brought to new to the table [46:22] in there. [46:25] >> I could be really [46:27] w try to be witty and say the new thing [46:31] about PHP unit 13 is that there is [46:34] something new. [46:36] But um unless you are familiar with um [46:41] how PHP units major versions normally [46:44] work that would not be funny. So let me [46:48] explain. So usually [46:52] um the first release of a new major [46:55] version is rather boring as in there are [46:59] no or only very few new features. [47:04] Why is that? because the uh the O [47:07] release which is always on the first [47:09] Friday of February is the annual [47:12] opportunity to [47:16] get rid of technical debt, remove all [47:19] the code for features that have been [47:21] deprecated for quite a while. Clean up [47:23] under the hood, bump the PHP version [47:27] requirement, things like that. And [47:30] this.0 release lays the foundation for [47:33] feature development throughout the year. [47:36] Um on the first Friday of April, June, [47:39] August, October and December um are the [47:43] feature releases and they usually are [47:47] the ones that bring new features. [47:50] This year it was a bit different [47:53] because the 13.0 release has a couple of [47:58] new features. [48:02] nothing. Well, that's not true. There [48:06] are there are some significant changes [48:09] in there. Um, so for example, there are [48:13] a couple of new eight to be exact [48:16] assertions that deal with arrays [48:19] comparing arrays for identity and [48:22] equality [48:24] from [48:26] very very strict like the order of the [48:29] elements matters, the key value [48:32] relationship matters and the triple [48:34] equal sign operator needs to be used all [48:38] the way to the other other end of the [48:40] spectrum where it's very loose. The [48:43] order of the elements does not matter. [48:46] The key value relationship does not [48:48] matter. Basically, the keys do not [48:50] matter. And we use a double equal sign [48:53] operator to only compare for equality [48:55] and not a type safe comparison. [48:58] And if you multiply that out, you you [49:01] arrive at eight different assertions. [49:05] And they have been like some of them [49:08] have been requested for quite a while. [49:11] Like I I remember Jordi from from the [49:13] composer project asking me about ones of [49:17] those eight. I forgot which which one it [49:19] was a couple of years ago and I never [49:23] really got around to doing that. And [49:25] then somebody else asked for for [49:28] something else. And then I [49:32] sat down with Jordi and Teo Fedri at um [49:38] Symphony Con in Amsterdam last year [49:41] and we discussed this for uh for a bit [49:44] and then arrived at okay if we are going [49:48] to do this then we need all eight of [49:51] these and um because if we only [49:54] implement one or two then people will [49:56] complain and say hey this this is [49:58] missing and why is this and not that? So [50:01] we imple so I implemented all eight of [50:03] them. [50:07] >> I would say the major change or major [50:10] addition improvement in 13 is two new [50:16] parameter matchers when working with [50:18] mock objects. [50:20] So in the past, prior to PHPUnit 10, we [50:23] had a parameter matcher that allowed you [50:25] to say, okay, [50:28] um I want this method or I expect this [50:32] method to be called three times and the [50:35] first time it needs to be called with [50:36] these parameters, the second time with [50:38] these parameters, the third time with [50:40] these parameters. [50:43] But the sequence was fixed and strict. [50:47] >> Mhm. And sometimes the order in which [50:52] these expected method calls happen [50:55] is not relevant. [50:58] And having then only the option of [51:01] having this fixed order becomes a [51:04] maintenance burden when you do a [51:08] refactoring of the code you're testing [51:10] and suddenly the events h or like like [51:14] um method calls happen in the in a [51:16] different order. [51:19] uh and the test fails although it should [51:21] not fail because the test is not [51:24] interested at all in the order but it is [51:26] because that's the only way the API [51:28] supported it and that was one of many [51:31] many many limitations and frustrations [51:35] with the old API we had prior to PHP 10 [51:40] and the old API was unfixable [51:45] without a backward compatibility break. [51:48] And believe it or not, back then I [51:51] arrived at the conclusion that the [51:54] minimal amount of backward compatibility [51:57] break would just be to delete this [51:59] method because changing it like keeping [52:03] it, fixing it and breaking backward [52:06] compatibility would have been a lot [52:09] harder with when when it comes to [52:11] migration because [52:13] it's it does not fail in obvious ways in [52:17] certain certain situations and you would [52:19] get false positives or false negatives [52:22] and I could was not able to figure that [52:25] out. Maybe I'm just too stupid. I don't [52:27] know. But back then I did not have a [52:29] solution. [52:31] So I deleted it and put on the road map [52:36] finding a replacement for that [52:38] functionality but never got around to [52:40] implementing that. [52:43] And then at the end of last year, I was [52:46] doing a training and one of the [52:48] attendees of my training said, [52:54] "Well, I'm missing this functionality [52:56] here. I I I really want to test this, [53:01] but I can't because this what this [53:04] feature was removed and there is no [53:06] replacement or I'm unable to find the [53:09] replacement." [53:11] um what gives please explain and then [53:14] then I explained the situation and she [53:17] said I understand [53:19] I'll use this ugly workaround I found on [53:22] stack overflow but I'm not happy with [53:25] that [53:26] and then a week after the training she [53:29] sent me a pull request and said I think [53:32] I have found a solution [53:35] um and it was a solution and it is the [53:39] solution that is now in 130 and this is [53:42] un like I said coming back to what I [53:44] said a couple of minute minutes ago this [53:46] is unusual that PHP like O release has [53:49] new features. [53:50] >> Mhm. [53:53] >> Because usually it's just clean up [53:55] technical debt [53:57] PHP version bump things like that. [54:00] >> Okay. [54:01] >> So the exciting thing about the 130 is [54:04] that there was something exciting about [54:06] it. [54:08] Normally it's intended to be boring. [54:13] >> Okay, I understand. Okay. Well, thank [54:15] you for for going through through that. [54:18] What have you got planned for this year? [54:21] What sort of features coming into it [54:23] over the next 12 months [54:27] >> that you're allowed to say? way that you [54:29] the way that you phrase the questions. [54:31] What what what have I planned that [54:35] that insinuates that I do have a plan? [54:42] >> Um, [54:43] >> okay. Is there anything that you know [54:44] you're going to be putting in? So, I can [54:47] tell you what I worked on over the last [54:49] couple of days, which I definitely had [54:52] not planned to do, but um I woke up one [54:56] morning last week and thought screw it. [55:00] I I've been annoyed and frustrated by [55:03] this limitation for 10 plus years. So, I [55:07] finally want to tackle that. And I got [55:12] most what I wanted to accomplish done in [55:15] about a day. And then I needed only two [55:17] more days um to clean it up and make it [55:20] actually work. Uh and by now you're [55:23] wondering what the heck is he talking [55:25] about. So I I rewrote the code that [55:30] serializes code coverage information to [55:33] a file, merges multiple of those files [55:38] into a single code coverage file and [55:41] then generates a report from that. while [55:45] solving all the bugs that have [55:47] accumulated in that area of of PHP unit [55:52] code coverage functionality over the [55:54] last 10 plus years. [55:56] So there is a command line tool in [55:59] addition to PHPUnit that is called PHP [56:01] COV which can merge code conference [56:06] information from multiple PHPUnit runs [56:09] and this is useful in at least two [56:12] scenarios. [56:14] one, you have so many tests that you [56:16] want to run them in parallel using um [56:20] wrappers around PHPUnit like par test or [56:23] parunit to just improve test um [56:27] execution speed [56:30] that works well. [56:32] But when you want a single unified code [56:36] coverage report for all your tests and [56:38] you run the tests in parallel, you need [56:40] to merge the code coverage information [56:42] from all the runs into a single one. [56:46] And [56:49] that merging was not very robust because [56:51] the serialized format that was used um [56:55] was not very good. [56:59] I hope it is a lot better now. I got [57:01] really promising feedback from the [57:03] maintainers of parunit and parest [57:06] uh already and some feedback from some [57:09] other people as well. [57:12] And [57:14] that might sound boring but it makes [57:17] something as essential as code coverage [57:21] reporting in certain [57:24] scenarios finally robust and actually [57:28] usable. [57:29] Yeah. Another scenario where you need [57:31] that is is if you have [57:36] operating system specific code paths in [57:39] your application. [57:42] So for example you you are an open [57:44] source project you need to support [57:47] for whatever reason Windows. So you also [57:50] run your tests on Windows but you have [57:52] certain lines of code that are only run [57:55] on Windows. Now when you run your tests [57:57] on Linux, those lines of code are not [58:00] run. So they are red in your code [58:02] coverage report. [58:04] If you run them on Windows, the lines [58:07] will be green, but other lines that are [58:09] specific to Linux will be red. So but if [58:12] you want to see the full picture, you [58:14] need to merge that into one. [58:16] >> Or you have code that is specific to [58:19] different database backends. Yeah, we [58:22] have Marco uh in the chat as far as I [58:25] can see at least and he will tell you [58:27] from the doctrine project they need to [58:30] test doctrine against all the databases [58:34] that are supported by doctrine [58:37] and some of them like I I would assume [58:41] most of them are not mutually exclusive. [58:43] So you can have the extensions in the [58:45] same setup, but maybe you do not want [58:47] that from a CI perspective [58:50] and have specific jobs in your CI [58:53] pipeline for the specific database back [58:54] ends. And then you need to merge that [58:56] together into one coherent report. Boom. [58:58] Same problem, just a different use case. [59:02] Anyway, that code is now in a much [59:05] better shape than it used to be. And [59:08] along the way, I rewrote the PHP COV [59:11] tool and finally wrote some [59:12] documentation for it, which I always [59:15] forgot to do. Um, so hopefully that will [59:19] be better. Now, [59:23] >> that one is a lot more important than [59:25] some people may realize. in PHP I just [59:29] remember that PHP unit 13.1 which will [59:31] be released at the beginning of April [59:34] will also bring [59:37] hopefully but I have I've said the [59:39] following sentence a dozen times over [59:42] the last two years it will hopefully [59:45] bring the final piece into PHP unit [59:50] to make most of Symphony's PHP unit [59:54] bridge superfluous [59:59] So I've I've worked a lot with the [60:02] Symfony developers over the last couple [60:04] of years to bring the features that that [60:07] are [60:09] useful not only to Symfony developers [60:12] but to all PHP developers. [60:15] Make them generic. Make them available [60:17] in PHP unit. And all of that has to do [60:20] um with issue handling. Yeah. like e [60:23] deprecated, e user deprecated and things [60:25] like that to properly report that and [60:28] filter [60:30] and basically filter based on is it a [60:34] deprecation in my code that is triggered [60:37] by my code. Is it a tri uh deprecation [60:40] in third-party code that is triggered by [60:42] other thirdparty code or is it a [60:44] deprecation in third party code that is [60:47] triggered by my code or is it a [60:49] deprecation in my code that is triggered [60:52] by third party code and it it's a [60:54] combinatoral explosion and it's a [60:57] nightmare to work on because it's [61:00] sometimes really bizarre and obscure [61:03] what types of edge cases you need to um [61:06] to to think of but I'm [61:10] like I said I've said I've said this a [61:13] dozen times over the last two years. I'm [61:16] hopeful that this is the final piece [61:18] that is missing from getting rid of most [61:21] of what the Symfony bridge uh or the PHP [61:25] unit bridge for Symphony is about. [61:31] >> Does sound uh very exciting. Yeah. [61:34] >> Yeah. Uh, we had a message from someone [61:38] on you that's watching on YouTube. I'm [61:40] not going to try and pronounce that [61:41] name. No offense. Just uh saying thank [61:45] you for your involvement in everything [61:47] that you've done. [61:49] >> Thank you for those kind words. You're [61:51] very welcome. [61:56] >> So there was a little convers [61:59] volunteering to rewrite PHP unit in [62:01] Erang. Go for it. [62:04] So I think we negotiated a bit after [62:06] that and we're now doing it in SIG. [62:15] I think the AI agent will not mind [62:18] whether they transform the PHP code into [62:22] Erlang, Rust or ZIK codes. [62:27] If you if you ever want to have a laugh [62:29] at anything that an AI produces, just [62:32] ask it to do anything slightly more [62:34] advanced than hello world in assembly. [62:37] It just goes, "Yeah, I don't know what [62:38] to do with this." Bit like most assembly [62:40] developers. See, a couple of weeks ago, [62:43] I wanted to find out how good that is [62:47] and asked an AI agent to write a really [62:53] simple routine [62:56] in Motorola 68K assembly. [63:00] Yeah, just turn the screen black and [63:02] draw a white line that scrolls from top [63:05] down from top to bottom and back up. [63:10] It confidently told me that it generated [63:13] the right code. The code sure enough [63:16] assembled correctly and I got an Omega [63:19] binary, [63:21] but when I tried to run it, it crashed. [63:30] >> Yes. [63:31] >> So, I have to say this is the episode [63:33] where I thought we wouldn't end up [63:34] talking about AI, but somehow we've got [63:37] back onto AI. [63:39] >> Yeah. Please don't. [63:40] >> Yeah, [63:41] >> I'm about to go to bed and I don't want [63:43] to have nightmares for one. [63:45] >> Well, let's let's let's go to something [63:48] that's um that that fascinated me. [63:51] Something you said just before we went [63:52] on there. You told us about the first [63:55] podcast you appeared on. [63:57] >> Mhm. [63:58] >> And it was to do it was a board game [64:01] podcast. I can see from your background [64:04] you got from what I can see quite a lot [64:06] of board games back there. I'm assuming [64:08] they're all board games. Um, [64:10] >> they are all board games. Yes. [64:12] >> Yes. Um, but you use them in your [64:15] training. [64:17] >> Yes. [64:18] >> And I'm intrigued to hear a little bit [64:19] more about that. So once upon a time I [64:23] was at a customer on site [64:27] way back when I used to travel a lot [64:31] because I did almost all my work onsite [64:37] at a customer [64:39] and I was there at the company for [64:42] something completely different than what [64:45] I'm going to tell you about. Um towards [64:48] the end of the week that I was there, [64:51] they said, "Well, we basically [64:54] did everything we wanted to do or wanted [64:58] to learn from you this week already, and [65:01] we had not planned this, but we would [65:03] really also like to [65:08] get started with testdriven development. [65:11] Can can can you show us testdriven [65:14] development?" and after you've shown us [65:17] a little bit of it, we would like to um [65:21] get started on ourselves and you coach [65:23] us while we do that. And I said, "Sure [65:25] enough, we can do that. [65:29] Give me an example of what we should [65:32] what I should build or what we should [65:34] build together in test-driven [65:36] development." [65:37] And they blanked. [65:40] They were unable to tell me something [65:43] that they wanted to do because [65:45] everything they could think of from [65:47] their domain. They were really sure we [65:51] would not be able to do that within a [65:54] day because it all they could think of [65:56] it was too large, too big, um too [65:59] complex. [66:02] And I refused to do something generic. [66:08] Mhm. [66:08] >> I did not want to do one of the cutters [66:11] or some some arbitrary bland you [66:18] run-of-the-mill example that everyone [66:20] knows. I wanted to keep it interesting, [66:24] not only for myself, but also for um for [66:28] the participants of the training. And [66:31] then that's when I noticed a shelf at [66:34] the back of the room, the training room [66:37] we were in. and it had board games in [66:39] it. And one of the games I knew and I [66:44] asked the people in the room, do all of [66:46] you know that particular board game? And [66:49] they all agreed, yes, we've all played [66:51] it dozens of times. That's great. Then [66:55] you know the rules. And that's what [66:56] we're going to do here today. We are [66:59] selecting [67:01] a subset of the rules from that game and [67:05] will implement [67:07] these rules in a test-driven fashion. [67:14] And I did that [67:18] out of me seeing like between me seeing [67:21] that game asking the question and [67:24] deciding we are going to do this couple [67:26] of seconds. [67:29] And that worked so well that I've done [67:33] that since then a couple of times [67:37] >> because it is something different [67:42] from the domain that the the [67:45] participants of such a training are used [67:48] to and work in day in and day out. [67:54] While it is still something that at [67:57] least some of them are familiar with or [67:59] can relate to and it's not [68:05] a simple example where you quickly lose [68:08] interest because it's either boring from [68:14] from the topic perspective or boring [68:16] from there is no challenge in [68:18] implementing that. So it keeps things [68:21] interesting. [68:25] So, I've done that with a couple of [68:26] games for like the first one that I did [68:29] was Pandemic, the original Pandemic. [68:32] Um, [68:33] before the pandemic. [68:37] Um, [68:39] and then I did it with Clans of Calonia. [68:41] I did it with Irish Gage, [68:45] uh, and some other games. Ticket to [68:47] Ride. [68:51] I even used chess once because that was [68:53] the only board game people knew and [68:56] wanted to do. [68:58] Also works. [69:01] I I've done a similar thing with domain [69:03] driven development. I've uh I've used um [69:06] Dungeons and Dragons as the example of [69:08] domain driven development because it [69:11] basically is a domain driven [69:12] development. [69:13] >> Yeah. The the whole book just gives you [69:15] the entire domain for Dungeons and [69:17] Dragons. [69:18] >> Yep. I did that as well, not with D&D, [69:22] but um with the system that is the most [69:25] popular one over here in Germany because [69:27] I was working with German developers and [69:29] they of course knew the system that I [69:32] played when I was a teenager way back [69:35] when. Yeah, [69:38] >> it's one that because the rules are so [69:40] clearcut. [69:42] >> Yes. It makes it so easy to demonstrate [69:46] any of the domain driven event driven [69:49] testing. [69:50] >> This basically put development on the [69:53] end of a word and you can probably teach [69:55] it with a board game. [69:57] >> Yeah, I've I've taught domain driven [69:58] design with a board game. I've done I've [70:00] uh trained test-driven development with [70:02] board games. [70:04] All of that works. Yes. [70:07] >> Interesting. Very interesting. [70:11] And once in a while I actually get to [70:13] play those games because most most of [70:16] the time I'm just [70:22] >> happens to tech quite a lot, isn't it? [70:24] There's board games afterwards varying [70:26] different forms. [70:27] >> Oh yes. Yeah. Um the both So um let me [70:31] get my days right. Normally open on the [70:33] Tuesday. So Tuesday and Wednesday [70:36] evenings there's normally a lot of ball [70:38] games going on. Um, you normally find me [70:41] in the corner playing chess with [70:42] someone. Um, there's always I think one [70:45] of the nights is generally you'll find [70:47] John playing poker with a table of [70:49] people. So, the poker comes up. But [70:52] yeah, there's all sorts of board games [70:53] and things uh get played. Um, John [70:57] normally brings a selection, then some [70:58] other people bring them all. Um, I I [71:01] can't remember what ones they are. Um, I [71:04] certainly can't remember which ones were [71:05] there last year because unfortunately I [71:06] wasn't I was I wasn't well. So most of [71:09] the week was just a blur to me now. I [71:11] don't remember any of it. Um, yeah, [71:14] that's uh it certainly certainly seems [71:17] to be a link between developers and [71:20] board games and I love board games and [71:22] yeah, I do I do love [71:25] >> trying out new new games and board [71:27] games. Yeah, once a once a year I go to [71:31] a board game weekend, which no longer is [71:34] just a weekend because by now it starts [71:36] on Thursday evening and goes all the way [71:39] to Sunday, [71:40] but at least 50% of the people there are [71:45] developers or [71:48] >> similar things. Yeah. [71:52] >> Cool. [71:54] >> All right. Well, I think uh on that [71:55] note, I think we're kind of coming to [71:57] the end of uh today. So, uh thank you [72:00] very much, Sebastian, for joining us and [72:02] talking to us about PHP units and uh how [72:05] we got where we are with with the with [72:08] um the testing framework, which [72:12] as far as we're aware most people use, [72:15] or if they don't, they should be using [72:16] it. [72:17] >> Yep. Um, and uh, yes, again, thank you [72:21] very much uh for for joining us and [72:23] giving us your your time today. We'll [72:26] let you go because I know it's you're [72:27] wanting to get off and go to sleep. Um, [72:31] so [72:32] >> thanks for having me. It was was a [72:34] pleasure. [72:34] >> Yeah. Well, thank you very much. And [72:36] hopefully our paths will cross again [72:37] very soon. Um, and we'll meet up and and [72:40] chat some more, I'm sure. [72:42] >> Yep. So, and thank you very much for [72:43] everyone for uh watching or listening, [72:46] however you're however you're [72:48] interacting with us and everyone that [72:50] was uh that participated live with us in [72:53] our chat. Um you can always go into our [72:56] Discord channel at any point. Um people [72:59] are great people are in there talking [73:00] about all sorts of things um in there [73:03] all week long. You don't have to be [73:05] there during one of our live shows. [73:08] Um, I've got my script up in front of [73:11] me, so I don't know if Chris has put up [73:12] the Discord link. Uh, no, he hasn't. [73:15] >> I haven't. [73:16] >> No. Come on, Chris. You got one, John. [73:18] You press buttons. [73:20] >> Right. Yeah. Join us over in our Discord [73:23] for the all those listeners. That is [73:24] discord.phparch.com. [73:27] And um, also don't forget to like and [73:30] subscribe on our YouTube channel. Help [73:33] us get these videos out to more people. [73:35] Would be great. Um, also don't forget [73:38] our magazine discount for all our [73:40] listeners. A live three will get you the [73:42] first three months free of a yearly [73:46] digital subscription. I'm getting there. [73:49] I'm getting there. I can get those words [73:51] out just about. [73:53] And don't forget, PHP Tech is almost [73:56] upon us. It's not long now. [73:59] It's It's a matter of what um where are [74:02] we now? We're almost [74:04] eight weeks. Is it eight? I don't know. [74:06] I should have counted how many weeks [74:07] away it is so we could say it, but yeah, [74:10] it's not long now. Not long now. Um, if [74:11] you haven't got your tickets, get your [74:13] tickets and it'll be great to see as [74:15] many people there as uh as possible. Um, [74:19] alongside that, we've got JStech. So, if [74:21] you're a JavaScript developer or you're [74:23] a PHP developer and you fancy looking at [74:25] a bit of JavaScript, we've got you [74:27] covered. We've got some uh great talks [74:29] uh all around JavaScript running at the [74:32] same time as uh PHP uh tech. And [74:35] finally, don't forget to head over to [74:37] our swag store. Um that is [74:41] store.phparch.com [74:43] uh where you can get all sorts of [74:44] t-shirts. And maybe next time we go [74:46] live, we'll actually have our t-shirts. [74:49] >> Maybe. [74:50] >> No, I don't think we'll remember. [74:52] I mean, we keep saying every show that [74:54] we there is one particular t-shirt we [74:56] both really like. We're going both going [74:58] to order and we we just never never [75:00] remember to order it. [75:02] Uh maybe if we keep saying it enough, [75:04] Eric and John will just send us one. [75:06] >> Yeah. I mean, it hasn't worked in 25 [75:09] episodes yet. So, [75:10] >> yeah. No. [75:12] Well, uh thank you very much for [75:14] everyone for listening again, Sebastian. [75:16] Thank you very much for for joining us. [75:18] Um keep up the the amazing work that you [75:20] you do. um with uh with just not just [75:23] the PHP, you're also involved in the PHP [75:26] Foundation as well. [75:29] Um and I think that is uh pretty much it [75:32] for us. I'm just trying to find the [75:34] right video outro video whilst I'm [75:37] talking. I can't do two things at once. [75:39] Um but thank you very much everyone and [75:41] we will all see you soon. Bye [75:44] >> bye.