# Java Testing with Spock

An episode of [CyberSecurity Summary](https://invisiblenetwork.ai/podcast/1816777677), 27 Sep 2026, 17 min.

Audio: https://dts.podtrac.com/redirect.mp3/api.spreaker.com/download/episode/73880233/testing_enterprise_java_with_spock.mp3

A technical guide published by Manning Publications that details how to use the Spock framework for software verification. The text explains that Spock is a Groovy-based tool that seamlessly integrates with Java projects, offering a more expressive and readable alternative to traditional frameworks like JUnit. Throughout the book, the author covers essential foundations such as Groovy syntax, the given-when-then testing structure, and advanced features like parameterized data tables. Readers are also guided through professional practices including mocking, stubbing, and performing integration tests within enterprise environments. Ultimately, the source serves as a comprehensive resource for developers looking to write concise and self-documenting test suites. You can listen and download our episodes for free on more than 10 different platforms: https://linktr.ee/cyber_security_summary Get the Book now from Amazon: https://www.amazon.com/dp/B0977ZJYWW?lv=shuf&channelId=500&plpRedirect=mhFallback&linkCode=ll2&tag=cvthunderx-20&linkId=41514c516cc26ed2e1ed8f6cf6bf4ee5&language=en_US&gaOptInStatus=true&ref_=as_li_ss_tl Discover our free courses in tech and cybersecurity, Start learning today: https://linktr.ee/cybercode_academy

## Transcript

[0:00] Speaker 1: You ever order like a piece of furniture online, You
[0:02] Speaker 1: click buy, and suddenly you get an alert that your
[0:05] Speaker 1: credit card was charged three times the amount shown on
[0:08] Speaker 1: the product page.
[0:09] Speaker 2: Oh man, the absolute dread. I mean, you just sit
[0:12] Speaker 2: there staring at the screen and the panic slowly sets
[0:14] Speaker 2: in as you realize your bank account is basically drained.
[0:18] Speaker 1: It is infuriating, but you know, if you look behind
[0:20] Speaker 1: the curtain, it is rarely just a random glitch. It
[0:23] Speaker 1: is usually a tiny invisible crack in this massive digital foundation, right.
[0:28] Speaker 2: And fixing those invisible cracks is what separates a functioning
[0:31] Speaker 2: company from well, a bankrupt one.
[0:34] Speaker 1: Yeah, and that is exactly why we are tearing into
[0:36] Speaker 1: the book Java Testing with Spock by Constantino's Couple on
[0:40] Speaker 1: as today. Welcome to the deep dive, by the way,
[0:42] Speaker 1: for you, the insanely curious learner.
[0:44] Speaker 2: Glad to be here because you know, this isn't just
[0:46] Speaker 2: about writing code. It is really about how massive enterprises
[0:50] Speaker 2: keep their digital skyscrapers from just collapsing under their own weight.
[0:54] Speaker 1: Okay, let's unpack this because we all rely on this
[0:57] Speaker 1: flawless software in our daily lives, right from ordering that
[1:02] Speaker 1: furniture to expecting our digital services to be available twenty
[1:05] Speaker 1: four to seven.
[1:05] Speaker 2: Absolutely, And the thing is writing the code is only
[1:09] Speaker 2: half the battle. Testing it to ensure correctness is I mean,
[1:13] Speaker 2: it's just as crucial.
[1:14] Speaker 1: If not more so, right, because the stakes are wildly
[1:17] Speaker 1: different depending on the app. I mean, if I'm using
[1:19] Speaker 1: a daily calorie tracking app and a bug logs my
[1:22] Speaker 1: Apple as five thousand calories, I might just get annoyed.
[1:26] Speaker 2: Yeah, you just delete the app. The blast radius is
[1:28] Speaker 2: just you exactly.
[1:30] Speaker 1: The consequences are super localized, but.
[1:32] Speaker 2: As software scales up to the enterprise level, that blast
[1:35] Speaker 2: radius expands exponentially. Take hotel reservation software for example.
[1:40] Speaker 1: Oh that's a good one, right.
[1:41] Speaker 2: A tiny logic error there doesn't just annoy one user.
[1:45] Speaker 2: It could double book hundreds of rooms across the country
[1:47] Speaker 2: in a matter of.
[1:48] Speaker 1: Seconds, which causes massive financial loss and like permanent brand damage.
[1:53] Speaker 2: Exactly, But financial loss is still on the lighter end
[1:56] Speaker 2: of the spectrum. Really, the book list systems where failure
[1:59] Speaker 2: is cat straphic like literally life and death. Yeah, like
[2:02] Speaker 2: hospital equipment monitors, right, hospital equipment, nuclear reactor controls, or
[2:07] Speaker 2: even defense systems tracking enemy ballistic missiles.
[2:10] Speaker 1: Wow. Yeah, if a defensive missile system has a logic error.
[2:14] Speaker 1: You don't exactly get a chance to push out a
[2:17] Speaker 1: bug fix the next morning.
[2:18] Speaker 2: No, you definitely do not. The system has to be
[2:20] Speaker 2: flawless the first time.
[2:22] Speaker 1: So testing is mandatory, obviously. But the book uses this
[2:26] Speaker 1: really brilliant sports equipment e shop example to illustrate why
[2:30] Speaker 1: testing a massive system isn't as simple as, you know,
[2:34] Speaker 1: just clicking a few buttons.
[2:35] Speaker 2: Yeah, that example is so relatable for developers. Imagine you're
[2:40] Speaker 2: given a seemingly simple task. Management says, hey, winter is coming,
[2:44] Speaker 2: let's put a twenty five percent discount on all ski
[2:46] Speaker 2: equipment for a limited time. Sounds easy enough, right, So
[2:50] Speaker 2: you write the code to apply the discount to the
[2:51] Speaker 2: ski category. You spin up a local version of the shop,
[2:54] Speaker 2: You put some skis in your cart, and you see
[2:56] Speaker 2: the price drop by exactly twenty five percent.
[2:58] Speaker 1: Perfect job done.
[3:00] Speaker 2: And simulate the offer expiring by changing your system clock
[3:03] Speaker 2: and the price resets.
[3:04] Speaker 1: It looks bulletproof, so you push it to production. You
[3:07] Speaker 1: go to sleep, and you wake up to a panicked
[3:09] Speaker 1: phone call from the CFO.
[3:11] Speaker 2: Yes, because the company is suddenly hemorrhaging money.
[3:13] Speaker 1: Because what you couldn't see what no single developer could
[3:16] Speaker 1: possibly hold in their head is that VIP customers already
[3:20] Speaker 1: received a permanent ten percent discount.
[3:22] Speaker 2: Exactly whoever wrote that VIP logic like three years ago.
[3:26] Speaker 2: They didn't anticipate your cysinal ski discount. They weren't coded
[3:30] Speaker 2: to be mutually exclusive.
[3:31] Speaker 1: So VIP's log on the system stacks the discounts and
[3:35] Speaker 1: suddenly they're getting thirty five percent off.
[3:37] Speaker 2: The skis, which pushes the sale price well below the
[3:41] Speaker 2: company's profit margin. They are buying out the inventory, and
[3:45] Speaker 2: the company is essentially paying people to take the skis away.
[3:48] Speaker 1: That is wild, and that is what the book calls
[3:51] Speaker 1: the complexity multiplier of enterprise software.
[3:54] Speaker 2: Right, that's the exact term. An enterprise codebase isn't a
[3:57] Speaker 2: small app built by a couple friends in a garage.
[4:00] Speaker 2: You're talking about hundreds of thousands, sometimes over two hundred
[4:03] Speaker 2: thousand lines of code.
[4:04] Speaker 1: With like five to twenty developers making changes simultaneously.
[4:08] Speaker 2: Right, and you have layers of legacy code written by
[4:10] Speaker 2: people who left the company a decade ago. No single
[4:13] Speaker 2: person knows how everything works anymore.
[4:15] Speaker 1: So the final price on those skis isn't just a
[4:17] Speaker 1: simple math calculation. It factors in whether the customer is
[4:21] Speaker 1: a first time buyer, normal, silver teer, or VIP.
[4:25] Speaker 2: Plus three different pupon types like personal, seasonal and special, right.
[4:29] Speaker 1: And ad hoc offers, warehouse time, and like thirty plus
[4:34] Speaker 1: product categories. It is a massive, tangled web of conditional logic.
[4:40] Speaker 2: A single user visible feature relies on a dozen different
[4:43] Speaker 2: code modules, and changing one module can inadvertently alter twenty
[4:48] Speaker 2: different features.
[4:49] Speaker 1: It brings me back to the skyscrape or plumbing analogy.
[4:52] Speaker 2: Oh, I love this analogy.
[4:53] Speaker 1: Right, you are a plumber hired to fix a leaky
[4:56] Speaker 1: pipe on the fourth floor. You find the valve, you
[4:58] Speaker 1: tighten it with your wrench. The league stops. But what
[5:02] Speaker 1: you couldn't see behind the drywall is that tightening that
[5:04] Speaker 1: specific valve just diverted all the water pressure away from
[5:08] Speaker 1: the thirty second floor because you didn't know they were connected.
[5:11] Speaker 2: Fixing a small puddle just shut down the entire penthouse.
[5:14] Speaker 2: And to push that analogy further, imagine the blueprint itself
[5:18] Speaker 2: is constantly changing while you're working because other plumbers are
[5:22] Speaker 2: getting conflicting orders from management.
[5:23] Speaker 1: Oh the back office communication breakdown.
[5:25] Speaker 2: Yeah. The book illustrates this with a table sorting scenario,
[5:29] Speaker 2: The sales manager tells developer A, hey, I need the
[5:33] Speaker 2: data table sorted by the total dollar value of the order.
[5:36] Speaker 1: Okay, makes sense for sales.
[5:38] Speaker 2: But meanwhile, the inventory manager pulls developer b aside and says,
[5:42] Speaker 2: I need those exact same tables sorted by the physical
[5:45] Speaker 2: volume of the items.
[5:46] Speaker 1: And neither manager talks to the other exactly.
[5:49] Speaker 2: Both developers go in write their perfectly logical code and
[5:52] Speaker 2: blindly ovohide each other's work because the human communication channels
[5:56] Speaker 2: are just as tangled as the code base itself.
[5:59] Speaker 1: So if that is the real invisible connections overlapping demands,
[6:03] Speaker 1: how does any company survive? My instinct if I am
[6:07] Speaker 1: running this e shop would be to just hire an
[6:09] Speaker 1: army of QA testers.
[6:11] Speaker 2: Just throw humans at the problem.
[6:12] Speaker 1: Yeah, before any code goes live, fifty people manually click
[6:16] Speaker 1: every possible combination on the website to make sure nothing broke.
[6:20] Speaker 2: You could try that, but human error still scales with
[6:22] Speaker 2: your headcount. Plus think about the sheer mathematical volume.
[6:26] Speaker 1: Of those tests, Like how many combinations are we talking.
[6:29] Speaker 2: To safely test your SKI discount against just the known
[6:32] Speaker 2: variables a human tester has to check. A first time
[6:34] Speaker 2: buyer with a personal coupon, then a VIP with a
[6:38] Speaker 2: seasonal coupon, then a normal buyer with an ad hoc offer.
[6:42] Speaker 2: Oh wow, you're looking at well over one hundred unique combinations.
[6:46] Speaker 1: For a single minor feature update.
[6:48] Speaker 2: For one feature that equates to four or more hours
[6:51] Speaker 2: of incredibly tedious data entry. The testers get fatigued, they
[6:56] Speaker 2: inevitably miss a combination, and a bug slips through anyway, And.
[6:59] Speaker 1: Meanwhile, you or highly paid developers are sitting idle waiting
[7:02] Speaker 1: for QA to finish checking their work.
[7:04] Speaker 2: Exactly, Developer productivity grinds to a total halt. This mindless
[7:09] Speaker 2: manual testing is the first common coping mechanism companies use,
[7:13] Speaker 2: and it is entirely unsustainable, which leads to.
[7:15] Speaker 1: The second coping mechanism, which honestly sounds even worse, is
[7:19] Speaker 1: what the book describes as treating the existing system like
[7:21] Speaker 1: sacred code.
[7:22] Speaker 2: What's fascinating here is that large older institutions, think legacy
[7:27] Speaker 2: banks or massive insurance firms, they look at the terrifying
[7:30] Speaker 2: risk of breaking their infrastructure and the impossibility of manual testing,
[7:35] Speaker 2: and they just surrender.
[7:36] Speaker 1: They just declare the existing code sacred.
[7:38] Speaker 2: Yes, they declare the core legacy code completely off limits.
[7:42] Speaker 1: You do not touch it, so developers can only build
[7:45] Speaker 1: like small additions around it.
[7:47] Speaker 2: Exactly. They build these fragile, isolated wrappers around the old
[7:51] Speaker 2: code because they are terrified of breaking the existing infrastructure.
[7:55] Speaker 2: It leads to massive code duplication.
[7:58] Speaker 1: But wait, if manual testing takes way too long and
[8:01] Speaker 1: not touching the code basically ruins innovation, how does anything
[8:05] Speaker 1: ever get built securely?
[8:06] Speaker 2: That is the million dollar question, and it leads to
[8:09] Speaker 2: the third reaction, which is the ideal solution. You build
[8:12] Speaker 2: an automated testing framework.
[8:14] Speaker 1: Okay, so essentially a machine doing the machine's work.
[8:17] Speaker 2: Yes, it acts as a tireless, meticulous early warning system. Generally,
[8:21] Speaker 2: engineering teams use a build server like Jenkins for example.
[8:24] Speaker 1: Okay, I've heard of Jenkins. How does that fit in?
[8:26] Speaker 2: Think of the build server as a separate, unbiased referee computer.
[8:31] Speaker 2: It runs in the background. The moment you the developer,
[8:34] Speaker 2: submit your new ski discount code, the build server wakes up.
[8:38] Speaker 1: And it runs all the tests automatically.
[8:40] Speaker 2: Exactly. It pulls down all the code into a pristine
[8:43] Speaker 2: environment and runs every single automated test the team is
[8:46] Speaker 2: ever written, usually in milliseconds.
[8:49] Speaker 1: So instead of a human taking four hours to click
[8:51] Speaker 1: through one hundred coupon combinations. Yeah, the referee computer does
[8:55] Speaker 1: it instantly.
[8:55] Speaker 2: Instantly, and if your new discount accidentally breaks the vip lot,
[9:00] Speaker 2: the referee instantly throws a red flag. It gives developers
[9:03] Speaker 2: the confidence to refactor and change code.
[9:06] Speaker 1: Because they know the machine will instantly catch any regressions
[9:09] Speaker 1: or conflicting requirement exactly.
[9:11] Speaker 2: You know, the safety net is there, Okay.
[9:13] Speaker 1: So if automated testing is the holy Grail, developers need
[9:17] Speaker 1: the ultimate tool to write those tests, which leads directly
[9:20] Speaker 1: to the core of this book's Spock.
[9:22] Speaker 2: Yes, enter Spock, the Groovy or framework.
[9:25] Speaker 1: So. Spock was created in two thousand and eight by
[9:27] Speaker 1: Peter Neederweiser with support from Luke Daily. It's used by
[9:31] Speaker 1: major players right.
[9:32] Speaker 2: Oh, absolutely, Netflix, Mango, Dbe, Apache, Tapestry. They all use it.
[9:37] Speaker 1: But there's a detail here that might confuse people. Spock
[9:42] Speaker 1: is a testing framework written in the Groovy programming language,
[9:46] Speaker 1: but it is used to test Java code.
[9:48] Speaker 2: Right, which sounds like it would be a huge headache.
[9:51] Speaker 1: Here's where it gets really interesting. If a framework is
[9:54] Speaker 1: written in Groovy, how does it natively test Java without
[9:58] Speaker 1: causing some massive trans bottleneck.
[10:01] Speaker 2: It works smoothly because of the underlying engine both languages share,
[10:05] Speaker 2: which is the Java Virtual Machine or JVM.
[10:08] Speaker 1: Okay, so they run on the same virtual machine.
[10:10] Speaker 2: Yes, when you write code in Java or in Groovy,
[10:13] Speaker 2: your computer doesn't execute that raw text. A compiler translates
[10:17] Speaker 2: it down into bytecode.
[10:18] Speaker 1: Which is like a highly optimized low level language.
[10:21] Speaker 2: Exactly. The JVM understands this backcode perfectly, and because Groovy
[10:25] Speaker 2: was specifically designed to compile down into the exact same
[10:28] Speaker 2: JVM bytecode as Java, the system literally cannot tell the
[10:32] Speaker 2: difference between the two at runtime.
[10:33] Speaker 1: Wow. So they're wearing different clothes, but underneath they have
[10:36] Speaker 1: the exact same.
[10:37] Speaker 2: DNA precisely because they share that DNA. Integration is seamless.
[10:42] Speaker 2: You just drop the Groovy library into your Java project
[10:45] Speaker 2: and Spock immediately understands how to interact with your Java classes.
[10:49] Speaker 1: Okay, So that explains how they talk to each other.
[10:52] Speaker 1: But most Java developers listening are probably thinking, wait, j
[10:55] Speaker 1: unit is the undisputed king of Java testing.
[10:58] Speaker 2: It definitely is. Everyone knows janet.
[11:00] Speaker 1: Right, So if jan it is already the king, why
[11:03] Speaker 1: did we need Spock to challenge it? Like, what makes
[11:06] Speaker 1: spock a one stop shop.
[11:08] Speaker 2: Well, Spock is actually a superset of jay in it.
[11:10] Speaker 2: It doesn't carry all the legacy burdens that jay in
[11:13] Speaker 2: It accumulated over the decades. It combines enterprise testing reliability
[11:17] Speaker 2: with built in mocking and stebbing.
[11:18] Speaker 1: Okay, let's unpack mocking and stubbing for the listener. What
[11:21] Speaker 1: does that actually look like in practice?
[11:23] Speaker 2: So imagine you want to test just the math logic
[11:26] Speaker 2: of a new price calculator in your app. You don't
[11:29] Speaker 2: want that test to accidentally reach out and paying the
[11:31] Speaker 2: live credit card processing API.
[11:33] Speaker 1: Right, or update the real inventory database, because then you're
[11:37] Speaker 1: introducing too many variables.
[11:39] Speaker 2: Exactly, you aren't just testing your calculator anymore. To isolate
[11:43] Speaker 2: your specific Java class, you create fake versions of its
[11:46] Speaker 2: external collaborators.
[11:48] Speaker 1: You fake the communication, so you tell your mock database, Hey,
[11:51] Speaker 1: when the calculator asks you for the user's loyalty tier,
[11:54] Speaker 1: don't look it up, just reply with VIP yes.
[11:57] Speaker 2: You put it in a perfectly controlled environment. Normally, in
[12:01] Speaker 2: the traditional j unit workflow, creating those fake inputs required
[12:04] Speaker 2: completely separate external libraries like machto or jmaw.
[12:08] Speaker 1: So you had to wire all these different tools together
[12:11] Speaker 1: just to run a basic isolated test exactly.
[12:14] Speaker 2: But Spock does it out of the box. It eliminates
[12:17] Speaker 2: that friction entirely.
[12:18] Speaker 1: That is a huge advantage just having a powerful engine
[12:21] Speaker 1: under the hood. But honestly, it's totally useless if it
[12:24] Speaker 1: is miserable for the developers to drive.
[12:26] Speaker 2: That is the truth, and that is where Spock makes
[12:28] Speaker 2: its most profound impact. Its revolutionary readability.
[12:32] Speaker 1: Which pivots us from technical capabilities to behavior driven development
[12:36] Speaker 1: or BDD.
[12:37] Speaker 2: Yes, BDD fundamentally changes the philosophy of what a test
[12:41] Speaker 2: should look like. Spock draws inspiration from earlier BDD tools
[12:44] Speaker 2: like jay Behave and.
[12:46] Speaker 1: It forces a really clear structure. Right, the given win
[12:48] Speaker 1: then flow exactly.
[12:50] Speaker 2: You stop testing the abstract math of the code and
[12:52] Speaker 2: start testing the actual behavior of the system from a
[12:55] Speaker 2: user's perspective.
[12:56] Speaker 1: Let's break down the specific code example from the book
[12:59] Speaker 1: listing one point one. It's a billing system that emails invoices.
[13:04] Speaker 1: The business requirement is just if a customer has an
[13:06] Speaker 1: email address, send them an electronic invoice instead of printing
[13:10] Speaker 1: a physical one.
[13:11] Speaker 2: Simple enough requirement, right.
[13:13] Speaker 1: And Spock breaks it down into a story first the
[13:15] Speaker 1: setup the given block given an invoice, a customer, a
[13:19] Speaker 1: mail server, and a printer.
[13:21] Speaker 2: Right, that sets the stage.
[13:22] Speaker 1: Then you have the trigger, the when block when the
[13:25] Speaker 1: customer has an email address, the action exactly, and finally
[13:28] Speaker 1: the expected outcome the then block. Then the invoice should
[13:33] Speaker 1: not be printed so zero times and an email should
[13:35] Speaker 1: be sent one time.
[13:37] Speaker 2: It is remarkably elegant, but Spock takes it one step further.
[13:41] Speaker 2: Because Groovy is so concise and flexible, it allows developers
[13:45] Speaker 2: to write their method names as full, natural English sentences
[13:48] Speaker 2: wrapped in quotes.
[13:49] Speaker 1: Wait, really, so instead of naming a test method something
[13:53] Speaker 1: convoluted with like underscores and camel case, you literally just
[13:57] Speaker 1: write it as a plain sentence.
[13:59] Speaker 2: You can literally really name the test Electronic invoices should
[14:02] Speaker 2: be sent to active email addresses as a complete English sentence.
[14:06] Speaker 1: That is incredible, So the readability factor is just off
[14:09] Speaker 1: the charts. The test code basically becomes self documented exactly.
[14:13] Speaker 2: And this bridge is a massive gap. A non technical
[14:16] Speaker 2: business analyst could read that exact given one then code
[14:20] Speaker 2: and verify that it matches the business requirements perfectly.
[14:23] Speaker 1: Without needing to know a single line of Java logic. Right.
[14:26] Speaker 2: But if we connect this to the bigger picture, we
[14:29] Speaker 2: also have to look at what happens when things go wrong.
[14:32] Speaker 2: Tests fail constantly, that's their job, true.
[14:35] Speaker 1: And usually a traditional test just gives you generic assertion
[14:38] Speaker 1: error error four h four something didn't match. Have fun debugging.
[14:42] Speaker 2: It's a massive time sink. But Spock provides meticulous error reporting.
[14:47] Speaker 2: When a test fails, Spock doesn't just throw a generic error.
[14:51] Speaker 1: What does it do?
[14:52] Speaker 2: It prints out a highly detailed, context aware diagram of
[14:55] Speaker 2: the exact line of code that failed. It shows the
[14:58] Speaker 2: specific values of every single variable at that exact millisecond.
[15:03] Speaker 1: Oh wow, so it literally shows you the inner workings
[15:05] Speaker 1: of the code at the exact moment of failure.
[15:08] Speaker 2: Yes, which saves developers hours and hours of debugging.
[15:12] Speaker 1: So what does this all mean? We started this deep
[15:15] Speaker 1: dive looking at a terrifying reality, an enterprise landscape where
[15:19] Speaker 1: a single code change is like tightening a pipe on
[15:22] Speaker 1: the fourth floor and inadvertently destroying the plumbing on the
[15:25] Speaker 1: thirty second floor.
[15:26] Speaker 2: A world of intersecting discounts and calcified legacy code.
[15:30] Speaker 1: Right, and developers being turned into stressed out QA testers
[15:34] Speaker 1: doing repetitive manual labor but then we saw how automated
[15:38] Speaker 1: testing frameworks provide the safety net to escape that nightmare.
[15:41] Speaker 2: And Spock weaves that safety net out of something stronger
[15:44] Speaker 2: and much easier to use, leveraging the JVM to combine
[15:47] Speaker 2: JUnit reliability with native mocking and stubbing.
[15:50] Speaker 1: And most importantly, introducing that plain English given when then.
[15:54] Speaker 2: Structure, which leaves us with a really provocative final thought
[15:57] Speaker 2: to ponder.
[15:58] Speaker 1: What's that?
[15:58] Speaker 2: Well, if tools like BOCH are evolving to the point
[16:01] Speaker 2: where tests are written in plain English so clearly that
[16:05] Speaker 2: non technical business analysts can read and verify them, how
[16:08] Speaker 2: might this change the structure of tech companies?
[16:10] Speaker 1: Oh? That is interesting, right?
[16:12] Speaker 2: Could the traditional heavily guarded wall between the business side
[16:16] Speaker 2: and the programming side eventually disappear entirely because.
[16:19] Speaker 1: The language of testing is becoming the language of business requirements?
[16:23] Speaker 2: Exactly? It could turn everyone in the organization into essentially
[16:26] Speaker 2: a partial software engineer.
[16:28] Speaker 1: That is a wild thought. When the people making the
[16:31] Speaker 1: rules can read the code testing the rules, the whole
[16:34] Speaker 1: dynamic shifts. Well. Thank you so much for joining us
[16:38] Speaker 1: on this deep dive. For you listening, keep learning, keep
[16:41] Speaker 1: questioning the technology that runs your world and we'll catch
[16:44] Speaker 1: you next time.

Shows are listed from Apple Podcasts' charts and directory, and Podcast Index where it is used. Every show and episode belongs to its publisher and plays from the publisher's own feed; this site hosts none of them.