Speaker 1: Hello, everybody, Welcome to another thrilling episode of JavaScript Jabber.
Speaker 1: I am Steve Edwards, the host with the face for
Speaker 1: radio and the voice for being a mine. But I'm
Speaker 1: still your host with me on the panel today, all
Speaker 1: the way from Tel Aviv, Israel's mister Dan Shapier.
Speaker 2: How are you doing, Dan?
Speaker 3: I'm doing well. How are you, Steve?
Speaker 2: Doing good? Doing good?
Speaker 1: It's Wednesday morning, first day back at school for kids here, so.
Speaker 2: That's always good.
Speaker 1: I'm still hot and toasty there in Tel Aviv as always.
Speaker 3: Yeah, when is it not? Yeah?
Speaker 1: Yeah, it's a little cooler here, starting to cool down
Speaker 1: a little bit, which is always a bummer, but.
Speaker 2: It is what it is.
Speaker 1: And our guest today coming all the way also from Israel,
Speaker 1: mister Joannie Goldberg.
Speaker 2: How are you doing, Yanni?
Speaker 4: Hey, hey, great, great Tom. I'm really happy to be
Speaker 4: here today. It's one degree cooler here comparing with Al Aviv.
Speaker 4: Very hot, but the good news that after two months
Speaker 4: as of being at home, kids are finally back at
Speaker 4: school yesterday or before, so.
Speaker 2: Yeah, back to work a little yes.
Speaker 1: And for those of you that might see Yohannis drink,
Speaker 1: he is not drinking and podcasting that is tea, not beer.
Speaker 1: I clarified that before the episode, so so not that
Speaker 1: it's not okay to drink and podcasts, but just clarifying.
Speaker 5: I literally drank beer on stage while giving certain talks.
Speaker 5: My contention is that it only made the talks better.
Speaker 2: Started listening up a little bit. Is that it Yeah,
Speaker 2: if you probably.
Speaker 4: Know, is it also legit in the States? I know
Speaker 4: it's you in Europe, it's okay. But if I drink
Speaker 4: at like it's the States during the talk will be
Speaker 4: considered PC.
Speaker 1: I've never heard anything against it. I guess it depends
Speaker 1: on how well you handle the the alcohol and well
Speaker 1: you stay on topic and have somewhat of a sense
Speaker 1: of humor.
Speaker 4: Then you're saying that the first two okay.
Speaker 5: In Germany, it's perfectly legit to have been at lunch
Speaker 5: during work days and legita required.
Speaker 3: Yes, there is something to that, and it's really good beer.
Speaker 4: Uh.
Speaker 5: When I worked at Wix, let's just say. Let's just
Speaker 5: say that we worked hard and played hard and sometimes
Speaker 5: played hard during working hours.
Speaker 1: Alrighty, So with that we will transition into the topic
Speaker 1: juju early topic of the day, which is JavaScript testing
Speaker 1: and what's going on in testing in the JavaScript world,
Speaker 1: so you on need to take it away.
Speaker 2: Where do we want to start?
Speaker 4: I'm sure you wanted to start by sharing a few
Speaker 4: words about myself and.
Speaker 2: My Now we don't care about that. We just want
Speaker 2: to know what you have to say.
Speaker 4: Now.
Speaker 1: I just yeah, seriously, sorry, I'm a little off track.
Speaker 1: Tell us who you are wire famous and where people
Speaker 1: can give you money or will say that for the end,
Speaker 1: just tell us who are true things? Surprise, surprise.
Speaker 4: I'm a developer, freelancer and a consultant doing full stack
Speaker 4: a lot of JavaScript, but more than anything else, really
Speaker 4: my love, my passion. The things that I'm trying to
Speaker 4: specialize in is that all developer workflow and specifically testing.
Speaker 4: I think that I've worked with more than forty organizations.
Speaker 4: Some of them are big ney you're probably recognize on
Speaker 4: improving their testing. So I literally said, over the shoulders
Speaker 4: of like hundreds of developers, as we try to craft
Speaker 4: tested are both efficient and yet simple. Done a lot
Speaker 4: of mistakes, learned, a lot, tried a lot of new frameworks,
Speaker 4: and I hope to share some of these lessons here today.
Speaker 5: Isn't the process to your basically cursor right tests?
Speaker 3: For me.
Speaker 4: Exactly exactly this actually we're about to cover. I would
Speaker 4: I would also cover some kind of testing AI trends,
Speaker 4: mostly the useful parts of AI. So yeah, okay, just
Speaker 4: to just to.
Speaker 5: Finish that particular point. The scary thing is afterwards, when
Speaker 5: you make changes and then the tests break, you tell it,
Speaker 5: Cursor fix the test for me, and you're not sure
Speaker 5: whether it's fixing your test to hide the bugs or
Speaker 5: fixing your code to fix the tests, or doing both
Speaker 5: or whatever it's It can be really interesting.
Speaker 4: That's this way, definitely. I mean, I think that one
Speaker 4: of the first things one should tune in Cursor or
Speaker 4: cloud code or whatever you're working is that you can
Speaker 4: let it work in yellow mode. But I think there
Speaker 4: is one exception any a human A human confirmation should
Speaker 4: be made anytime a test is changed. You may change
Speaker 4: my production code, I may inspect each and every nine
Speaker 4: or not, I don't know, but a test changed should
Speaker 4: supervise that that's.
Speaker 3: My That's a good take. I think.
Speaker 1: I can't think of any time I'm just going to
Speaker 1: say here writing some code and then committed or do
Speaker 1: whatever without looking over it and making sure it works.
Speaker 3: Well.
Speaker 5: Yeah, that's easy to say, and everybody starts with good intentions,
Speaker 5: but at a certain point in time, you know, especially
Speaker 5: when you're under the gun and certain things and things
Speaker 5: seem to work and you build a certain level of trust.
Speaker 5: I've known people to almost even engineers, almost get to
Speaker 5: the point of almost vibe coding their way through projects.
Speaker 5: And I think you Only's statement that if you've got
Speaker 5: good test coverage, then ensuring that the tests are properly
Speaker 5: maintained and reviewed is a good way to add a
Speaker 5: significant layer of trust and security around your vibe coding.
Speaker 4: Yeah, I agree with both. I think that people have
Speaker 4: various degrees of how much they supervise AI generated God,
Speaker 4: I'm just saying that the least conservative one can be
Speaker 4: is at least guard you're testing. You might do this
Speaker 4: also for the production cod but I think that letting
Speaker 4: AI also change tests has to change God. This is
Speaker 4: the highest amount of frizk one may take.
Speaker 5: Yes, Okay, then, so what are the latest and greatest
Speaker 5: trends when it comes to tests, aside from having AI
Speaker 5: do all the coding for us?
Speaker 4: Yeah, so I'll kind of mention some kind of super
Speaker 4: trends and are very impactful changes, and then we can
Speaker 4: dig dive deeper into each one of them, at least
Speaker 4: the ones that we found interesting. So I think there
Speaker 4: is always in testing one kind of everlasting progress in
Speaker 4: which we always we try to get our tests to
Speaker 4: be more production like without paying the price of So
Speaker 4: in the past two years we keep seeing this progress
Speaker 4: and in this in front and the front and world.
Speaker 4: For the first time, I think like we ad React
Speaker 4: testing library ruling this world for a lot of time
Speaker 4: tests that runs in a jazz things that's for the
Speaker 4: first time it's safe to say that tests don't run
Speaker 4: in the browser, that are not visual are almost out
Speaker 4: of scope. There are many new ways and frameworks to
Speaker 4: run your tests in the browser and get the full
Speaker 4: visual experience and the confidence, so it's more like production.
Speaker 4: But some of them run really fast, so you're not
Speaker 4: paying the price of like full full blown end to
Speaker 4: end framework on the back inside it means that you
Speaker 4: having a micro service, you can more easily now run
Speaker 4: it on your computer with all the layers and almost
Speaker 4: light production infrastructure, and again without paying a tremendous price.
Speaker 4: I think these are bold and the changes that we're seeing,
Speaker 4: and we I guess we will dig deeper into the
Speaker 4: specific tooling.
Speaker 5: And just to clarify, there are obviously layers to tests,
Speaker 5: so there I don't know if you should refer to
Speaker 5: them as higher or lower layers. It's just different positions
Speaker 5: in the testing cycle. So you've got obviously stuff like
Speaker 5: unit tests, which should be very relatively small, relatively straightforward,
Speaker 5: and certainly very very fast, and they usually don't need
Speaker 5: special wiring, although you know a certain degree or a
Speaker 5: certain amount of mocking is often involved. Then you've got
Speaker 5: integration tests, and you've got into end tests. It seemed
Speaker 5: to me that when you were talking about the improvements
Speaker 5: in our ability to do effective, efficient and performance testing,
Speaker 5: you were mostly talking about integration tests and end to
Speaker 5: end tests and less about unit tests.
Speaker 4: Correct yes and a little no. I mean, I think
Speaker 4: at first there is a trend. I'm not advocating, by
Speaker 4: the way, on anything. I'm just trying to cover what
Speaker 4: like trends that I observed. And I think another trend
Speaker 4: is seeing less unit tests and more kind of component
Speaker 4: page integration tests. But so called the testing diamond. It's
Speaker 4: a kind of an emerging concept where you should write
Speaker 4: more integration test but with the new tooling, even if
Speaker 4: you write unit tests like take a framework that we
Speaker 4: will cover with that. It's called VITAS browser mode. Even
Speaker 4: your unit tests run in the browser. Now think about it.
Speaker 4: Not all the unit tests in the world are pure.
Speaker 4: You might test the models that actually doing some stuff
Speaker 4: with the web APIs. So instead of running it in
Speaker 4: no JS with polyphils and trust and trust the similarity,
Speaker 4: it runs your test in a real browser and Chromium
Speaker 4: for example. So even your unit test gains more kind
Speaker 4: of production like experience. Does this make sense?
Speaker 3: Yes, it does, although it's I need to.
Speaker 5: Think about what I think about it. It's kind of
Speaker 5: a recursive statement because really, when I'm thinking about unit tests,
Speaker 5: I'm really trying in most cases to be as stateless
Speaker 5: as possible and consequently not be dependent on having access
Speaker 5: to a browser dome, which is kind of like persistent
Speaker 5: by the definition.
Speaker 3: And so I'm.
Speaker 5: Not sure that this is where I want my unit
Speaker 5: tests to go necessarily, but I certainly appreciate the fact
Speaker 5: that we don't need to mock browser a p I
Speaker 5: S domin p I S, which is always let's say,
Speaker 5: less than ideal. But why do you think that is
Speaker 5: what has changed that has made this What has changed
Speaker 5: that has made this possible?
Speaker 3: Now? That was not available before.
Speaker 4: Yeah, first forced margining that I fully agree. The real
Speaker 4: value is in is in integration tests and about page
Speaker 4: testing or component tests, also in end to end. In
Speaker 4: unit test, it's indeed less significant. So it's mostly if
Speaker 4: if we if we double double click into the front
Speaker 4: end word for a start. I think now there is
Speaker 4: a key up from decisions the team should make. There
Speaker 4: is kind of a triangle decision between three different frameworks
Speaker 4: for testing components and pages, and one of them is
Speaker 4: relatively One of them is is new. It's for the
Speaker 4: past two years, and it makes running visual test in
Speaker 4: the browser almost as fast as unit test. So there
Speaker 4: was a lot of people trying to avoid that kind
Speaker 4: of visual experience because of the hassle involved. But with
Speaker 4: some of the new frameworks like vitest browser mode and
Speaker 4: the new storybook model, it becomes easier faster, so you
Speaker 4: have less reasons not to just hey, let's test it
Speaker 4: like where the user lives. And maybe it's worth at
Speaker 4: some point explaining what is vitest browser mode, how does
Speaker 4: it stack with playwright go for it?
Speaker 3: Now?
Speaker 2: Is that the same as v test UI this browser mode?
Speaker 4: Ah, not exactly, because you can you can also have
Speaker 4: vites I with unit tests and browser mode is a
Speaker 4: new sub frameworks sort VI test and to zoom out
Speaker 4: for a second, I think that we have now three
Speaker 4: measure and good options in the front and word that
Speaker 4: one must make a decision up front. The first one
Speaker 4: is Playwright, the good all known Playwright, very reputable, very
Speaker 4: reputable frameworks that is being very popular, which allows you
Speaker 4: to test your system as is like you can spin
Speaker 4: up a whole page and you get a real page
Speaker 4: in a browser, but you get the all the you
Speaker 4: get the entire you get d their application with the
Speaker 4: router and the state and a lot of things beyond
Speaker 4: the page level or the component what you want to test.
Speaker 4: So the performance is like a little of concerning Playwright
Speaker 4: even when you mock the back.
Speaker 5: Correct me if I'm wrong. Playwright is essentially just a
Speaker 5: headless Chrome with api is to automate various tasks. That's
Speaker 5: more less it right.
Speaker 4: Yes, and maybe a little more because it can run
Speaker 4: your test in other browsers as well, like run the
Speaker 4: test once and get it running in Chrome or Safari
Speaker 4: or anything.
Speaker 5: Yeah, because they basically later on added support for the
Speaker 5: same APIs as I.
Speaker 4: Recall exactly they imported kind of a CDP protocol for
Speaker 4: other browsers exactly. But on top of this, they also
Speaker 4: have a very nice and stable API to make the
Speaker 4: experience of interacting with pages less flaky. So for example,
Speaker 4: if you're trying to assert on something, they will take
Speaker 4: care to retry in wait and until that condition is
Speaker 4: met on the page. So the overall testing experience is
Speaker 4: really great, and.
Speaker 5: It replaced all the frameworks like Cyprus and Selenium.
Speaker 4: Right exactly exactly. It is.
Speaker 5: Okay, So how is v test browser mode different from Playwright.
Speaker 4: Yeah, so first worldt mentioning mentioning is that the viittest
Speaker 4: browser mode is using Playwright under the hood, so you
Speaker 4: get a battle tested engine that you can trust. But
Speaker 4: what they try to do Playwright is a little bit
Speaker 4: disruptive to front and testing. So if you take traditional
Speaker 4: front and testing with people used to work with things
Speaker 4: like React Testing Library, the syntax of React Testing library,
Speaker 4: the concept of React Testing library supporting from there to
Speaker 4: Playwright was a little disruptive. Vitus Browser mode allows you
Speaker 4: to take your existing test or learn nothing new, use
Speaker 4: the same syntax, same concept, only instead of running it
Speaker 4: in nogs like React Testing Library, you run it in
Speaker 4: real browser, which obviously allows you to see. You probably
Speaker 4: know that that really nasty experience when you with React
Speaker 4: testing library and the test failed. What you see on
Speaker 4: the screen is three hundred lines of XML of HTML
Speaker 4: in a CLI in which you try to understand in
Speaker 4: this my component, how does it look like? What's wrong here?
Speaker 4: I mean nobody wants to travel shoot test in HTML
Speaker 4: over CLI. With this browser mode, you can see them
Speaker 4: in a browser and benefits from all of the Chrome
Speaker 4: Developer tool bar perks. So that's that's the premise. That's
Speaker 4: the obvious upside. They also make it like you know,
Speaker 4: vitt stands for fast in French, with the word wit
Speaker 4: is fast in French, and they they stand up to
Speaker 4: their reputation like I can I already use it in production.
Speaker 4: It's amazing. I can like test then entire page, some interactions,
Speaker 4: sometimes specific scenario in two hundred milliseconds. It's like blazing fast.
Speaker 4: You click on a button and you don't have enough
Speaker 4: chance to see what happened on the screen. So the
Speaker 4: performance is really awesome. With that, there are some cons
Speaker 4: that should be mentioned as well. It's very new, it's
Speaker 4: still tagged as experimental for like two years or so,
Speaker 4: and so's it's it didn't yet stand the battle of
Speaker 4: time like Playwright, And there are many other other decisions
Speaker 4: that were made that are that might appeal to some
Speaker 4: teams and not to others. But it's definitely a bold
Speaker 4: opportunity I think now in twenty twenty five for testing
Speaker 4: and I could not finish that. I'm sorry. This is
Speaker 4: kind of a mini mini TED talk. But there is
Speaker 4: also Storybook, and Storybook now change their model and now
Speaker 4: they're using Vita's browser mode under the hood, which use Playwright.
Speaker 4: So you have three options. You know that Russian doll
Speaker 4: which is called I believe Matroyshka Babushka or matroys Career.
Speaker 4: It's kind of a nested doll. So what we have
Speaker 4: now the in the testing space, it's a troche car,
Speaker 4: so you have to play right or VI test brother
Speaker 4: mos that you just play right, or storybooks that use
Speaker 4: you got idea and you have to make you have
Speaker 4: to make the choice.
Speaker 5: So if you're starting a new front end project today,
Speaker 5: and let's say that you're using one of the two
Speaker 5: leading options, I don't know how familiar you are with them.
Speaker 5: Either React, which is approximately fifty percent of the market
Speaker 5: or view which is approximately twenty to thirty percent of
Speaker 5: the market, and you need to do and you want
Speaker 5: to do testing because we started with testing for the
Speaker 5: front end.
Speaker 3: What would you use?
Speaker 4: Yeah, that's that's first. Very I think that the choice
Speaker 4: is really hard today. I had to choose for a
Speaker 4: customer like two weeks ago, and the decision is really hard.
Speaker 4: So from one hand, Eileen Tower being conservative and say, hey,
Speaker 4: let's use play right. It works. It's like the most simple,
Speaker 4: it's like the last layer. It's simple, it's proven, let's
Speaker 4: just use it again.
Speaker 5: Playwright in this case is for mostly for the end
Speaker 5: to end tests.
Speaker 4: Right, or you can use it also for components, for
Speaker 4: for component or page testing. It it has great tooling
Speaker 4: to allow you to mock your bacond and I think
Speaker 4: I think that for the majority of the testing front
Speaker 4: and team want to mock the beacon. But yeah, you
Speaker 4: can also run in.
Speaker 5: Well, let's put it this way, if you're not mocking
Speaker 5: your back end, then you're by definition dependent. It's almost
Speaker 5: it kind of almost means that by definition your tests
Speaker 5: are going to be flaky at least some of the time.
Speaker 5: If you do involve if you do involve the back
Speaker 5: so so yes, if you want to go for a
Speaker 5: operations of concerns, you want to mock external services reduce
Speaker 5: the amount of dependencies that you have on external services
Speaker 5: and that includes your own back end.
Speaker 4: Totally agree, it's slower, it's more flaky. But my highest
Speaker 4: concern with end to end is actually that it's really
Speaker 4: hard to simulate things beyond heavy passes. So think about it.
Speaker 4: You want to test now that the user is disabled,
Speaker 4: it's a premium user. You get twenty records, all of
Speaker 4: the things that are beyond the simplest response. With real
Speaker 4: back end, it might be very hard to tune the
Speaker 4: backet into each and every scenarios that you want. However,
Speaker 4: when you mock it, you can simply just say, hey,
Speaker 4: I want this response, I want that response.
Speaker 3: Yeah.
Speaker 5: On the other hand, when you're mocking it, you're basically
Speaker 5: inventing the responses, so it's not necessarily how the system behaves.
Speaker 5: It's not really end to end if it's mocking.
Speaker 1: I mean when you normally like spin up like a
Speaker 1: maybe this is what you're talking about with mocking, but
Speaker 1: basically create a test database or a copy of your database,
Speaker 1: spin one upset it. You know, you got your data
Speaker 1: in it and then run your tests. Are actually using
Speaker 1: a database. It's not your Pride database obviously, but at
Speaker 1: least you have a clone and a real database that
Speaker 1: you're interacting with, because I know, speaking personal experience, a
Speaker 1: lot of times that's that's valuable testing.
Speaker 4: Yeah, yes, but I think that first before answering that
Speaker 4: I'd like to repeat to a dance. And I think
Speaker 4: it's like a key point here. If you're doing naive mocking, Okay,
Speaker 4: I'm just walking some Jason. Yeah, you are now at
Speaker 4: the risk of doing things that are not exactly the
Speaker 4: same in production, and this is why you also need
Speaker 4: contract testing. And I think this is definitely a topic
Speaker 4: we want to double click into later because there are
Speaker 4: a new interesting tooling in the JavaScript space related exactly
Speaker 4: with this problem. How do you create smart and aligned mogs?
Speaker 4: Now to this one. Yeah, in a simple case, it's
Speaker 4: just crawd applications, So you set up something in the
Speaker 4: database and you display them. But in many cases, creating
Speaker 4: the server response is much harder than this. Let's give
Speaker 4: you an example. One of my customers, is there a
Speaker 4: user entity and it might get disabled? How does it
Speaker 4: get disabled, there is some chron job running every minute
Speaker 4: and concluding that the user is disabled. So how would
Speaker 4: you create a disabled user from a test and make
Speaker 4: the back end run a chron job and tag it.
Speaker 4: It becomes much so much harder than just returning one line. Hey,
Speaker 4: just give me a disabled user, Jason, am I being
Speaker 4: clear on this point.
Speaker 5: No, it's It's obviously true like getting an application to
Speaker 5: do what you exactly what you want and can be challenging,
Speaker 5: and configuring a certain backend application to replicate certain scenarios
Speaker 5: is a problem. Just think about, you know, the scenario
Speaker 5: where a customer tells you that they're experiencing a certain problem,
Speaker 5: and maybe you even have traces that kind of show
Speaker 5: the problem the way that the customer is experiencing it,
Speaker 5: and now you're trying to replicate that scenario in the
Speaker 5: lab in order to debug it. We all know how
Speaker 5: challenging that can be. So I totally agree that replicating
Speaker 5: weird behaviors or edge certain edge behaviors that are legitimate
Speaker 5: and you want to test for in an actual environment
Speaker 5: that simulates production can be challenging, and it's often much
Speaker 5: easier to just play recordings of back end responses and
Speaker 5: you know, effectively mocking the back end it can be
Speaker 5: much much easier. Likewise, also mocking the front end.
Speaker 3: You know you want to.
Speaker 5: Test the back end, says system, then you might use
Speaker 5: some sort of I don't know, just post things out
Speaker 5: of Postman or whatever or playwright rather than actually having
Speaker 5: an actual front end that you know you create a
Speaker 5: process that clicks through. It can be much more challenging
Speaker 5: and more complicated than length fear.
Speaker 1: So is there a point, you know, Joanni, with that
Speaker 1: example you gave with the Crown job, is there a
Speaker 1: point where you have to say, Okay, we can't test
Speaker 1: everything in an automated test and maybe we have to
Speaker 1: do something manually or do you always work under the
Speaker 1: assumption that everything in Proude can be handled with an
Speaker 1: automated test.
Speaker 4: Yeah, so I'd say, based on my experience, as long
Speaker 4: as you stick to gray box testing. When I say
Speaker 4: gray box testing, it's a test that you don't test
Speaker 4: the entire system. You test one component. You test like
Speaker 4: the user like you just put things in and expect
Speaker 4: some outcomes. But you also run on the same process
Speaker 4: like that application. You can simulate anything I didn't encounter
Speaker 4: anything that is not simulated that it's hard to simulate
Speaker 4: as long as you are your test and the col
Speaker 4: under testing within the same process. In terms of ROI yeah,
Speaker 4: I would definitely prioritize and focus on first on the
Speaker 4: things that the user does and the things that are
Speaker 4: likely to happen and where the bugs are more severe.
Speaker 4: But in terms of the technical capability of simulating stuff,
Speaker 4: I think that today's in the jobs critical system, I
Speaker 4: rarely encounter the situation that something was not reproducible.
Speaker 5: And I'll add to that that manual testing is kind
Speaker 5: of like by definition anecdotal, and I hate to depend
Speaker 5: on anecdotal evidence of correctness. And so even if if
Speaker 5: if you do a certain amount of manual testing, then
Speaker 5: record that testing and then turn it into an automated script,
Speaker 5: it doesn't need to stay manual forever. So a certain
Speaker 5: amount of manual testing, especially for I don't know complex systems,
Speaker 5: might be required, but again try to automate it going
Speaker 5: down the line.
Speaker 4: Definitely agree. I also have if someone is interested in articles,
Speaker 4: that's called testing the dark scenario of your back end,
Speaker 4: in which I've shown in an OGS application how each
Speaker 4: in seven lines tests no test there was more than
Speaker 4: seven lines. You can test really critical scenarios. It usually
Speaker 4: teams don't test, like, for example, test that when your bootstrap,
Speaker 4: your your beacon bootstop phase fails you then you get
Speaker 4: the right monitoring or test that when your live liveliness
Speaker 4: route is not behaving correctly, you get the right thing.
Speaker 4: Or when you know, very common in JavaScript word, when
Speaker 4: there is a process uncut exception or one hundred that
Speaker 4: rejection is happening in your application, do you do the
Speaker 4: right thing? This is a critical event. I mean your
Speaker 4: process might just crush. Do you test this? I showed
Speaker 4: out like in five lines of code you can also
Speaker 4: cover these advanced or endling passes. So yeah, I think that.
Speaker 5: So again to summarize what we've talked about so far,
Speaker 5: So basically what you're saying is that you're kind of
Speaker 5: promoting more sophisticated tests, usually component level tests or integration tests,
Speaker 5: less unit tests, and that using modern tooling that you
Speaker 5: mentioned like Playwright, like v test, browser mode, and like
Speaker 5: the storybook testing, it's much easier to do than it
Speaker 5: used to be, is basically what you're saying. If I
Speaker 5: understand correctly.
Speaker 4: Yeah, much easier than before. And i'd say, I mean
Speaker 4: I'm not against unit tests, but I think that for
Speaker 4: a start, your first step should be what the user
Speaker 4: is doing. And the user is not stretching functions or models, right,
Speaker 4: The user is visiting a page. So I think that
Speaker 4: the first things that you should test is your page,
Speaker 4: how the user interact, and then, as you call it,
Speaker 4: if you realize some complex, highly complex logics that you
Speaker 4: want to isolate, testing isolation for better whatever performance, then yeah,
Speaker 4: go for unit tests. But I think this is kind
Speaker 4: of contextual and optional.
Speaker 5: Well, to be fair, unit tests actually were kind of
Speaker 5: born out of TDD, So initially the concept of unit tests,
Speaker 5: at least for people who take that approach, is basically,
Speaker 5: we first write the tests, then we write the code.
Speaker 5: Now AI writes the tests and the code, so that's
Speaker 5: less that approach to be Also, to be fair, I've
Speaker 5: never been able to adopt the TDD model. Maybe I'm
Speaker 5: too much set in my ways. It just doesn't seem
Speaker 5: to be the way that I think. But I have
Speaker 5: gotten value from unit tests. The main advantage of unit
Speaker 5: tests is they're very lightweight, so they're almost effectively free
Speaker 5: to run, and they run, and I have them run
Speaker 5: constantly because you know, I don't care and if something break,
Speaker 5: it's there. They test very specific things so you get
Speaker 5: an instantaneous indication of where that problem is, so you
Speaker 5: don't need to think about Like with and let's say,
Speaker 5: especially the end to end tests. You know the test fails, Okay,
Speaker 5: why did it fail? It often requires pretty significant amount
Speaker 5: of investigation in order to understand why in end to
Speaker 5: end tests failed. And like we talked about before, it
Speaker 5: could also be related to certain things that to you know,
Speaker 5: flaky tests because you're dependent on external services. With unit tests,
Speaker 5: you're not dependent on everything and anything. You're just testing
Speaker 5: your own code. It runs very quickly. You're testing a
Speaker 5: very specific function. That's say, and.
Speaker 3: You know I've introduced I made a change that function.
Speaker 3: That's why it breaks.
Speaker 4: Couldn't agree more. You know, I observed once something very
Speaker 4: interesting that can it back. For those of you are
Speaker 4: not familiar with, Can is kind of the father of DDD,
Speaker 4: A person who should really appreciate unit test and he
Speaker 4: said in one of his blog posts, unit tests give
Speaker 4: up predicting suitability to production and inspiring confidence. So it's
Speaker 4: not about product confidence at all. It's about being writeable,
Speaker 4: fast and specific. Now I think that most of the
Speaker 4: developers are looking in testing for confidence, and yes, it
Speaker 4: turns out it's not only about this.
Speaker 5: Yeah, there's that famous picture about the difference between unit
Speaker 5: tests and integration tests, about you know, building urinal in
Speaker 5: such a position that when you open the bathroom stall door.
Speaker 3: You can't actually get at it.
Speaker 5: So everything is fine at the unit level, at the
Speaker 5: unit level, but when you put it all together, it
Speaker 5: doesn't work. The only we've seem to have lost your picture.
Speaker 3: You're still with.
Speaker 4: Us, Yeah, I'm working on fixing the camera. The good
Speaker 4: news is that I'm still online. Yeah, okay, And I
Speaker 4: think it worth just revisiting for one last minute that
Speaker 4: that crucial decision between the three front end things. So
Speaker 4: we've mentioned playwright. I think that storybook and Viness browser
Speaker 4: mode are also great options. And we didn't story books
Speaker 4: or storybook if you have a design you asked me,
Speaker 4: what would I pick? So, if we're having a design
Speaker 4: system and rely a lot of small components that we
Speaker 4: tend to communicate and testing isolation, storybooks gives a very
Speaker 4: compelling package in which we get first a great workflow
Speaker 4: of visualizing our component and documenting them, but also a
Speaker 4: great new testing experience. So you write a test once
Speaker 4: and you get both accessibility testing. If you have some
Speaker 4: accessibility issue, you are covered visual regression testing without writing
Speaker 4: any other test out of the box, if you're if
Speaker 4: you are out of the box, and if you sharing
Speaker 4: your credit card, visual testing and also also functional testing
Speaker 4: using playwright under the hood. So you get where.
Speaker 5: Say visual testing just to verify that you understand your terminology.
Speaker 5: You basically mean that if I accidentally, I don't know,
Speaker 5: change the font or something, it will break my test
Speaker 5: because the content, the actual pixels on the screen are
Speaker 5: not the same as they're supposed to be.
Speaker 4: Exactly. It should be smarter than this, and it should
Speaker 4: realize and detect significant changes from like minor improvement, but
Speaker 4: exactly this. Since that functional tests can tell you about.
Speaker 4: So your side menu is crewed, something some I don't know,
Speaker 4: something is totally broken on the screen, a big change
Speaker 4: in the layout.
Speaker 5: You put a red background or something for testing purposes
Speaker 5: and then forgot to remove it.
Speaker 4: That's that's that's a nice example. Yeah, so storybook gives
Speaker 4: you all this together interesting option. On the other end,
Speaker 4: it's the more sophisticated option. It's it's all the storybook
Speaker 4: narratives and its browser modan hand play, right, So you
Speaker 4: have a lot of moving pieces to handle.
Speaker 5: Is it open source? Is it? Is it a paid
Speaker 5: product or service?
Speaker 3: What? What is it?
Speaker 4: It's open source, it's a free product, except I think
Speaker 4: this is how they make the revenues. Accept the visual
Speaker 4: regression test. What you just mentioned this one is is
Speaker 4: a paid service.
Speaker 3: Okay, cool?
Speaker 1: Hey, just to clarify terms. I know we've talked about
Speaker 1: different types of testing. We talked about unit testing, integration testing,
Speaker 1: and then testing visual testing.
Speaker 4: Uh.
Speaker 1: The one I always get hazy on is a difference
Speaker 1: between I guess what integration testing is how you find
Speaker 1: that versus unit tests versus and the s test? What
Speaker 1: excuse me, end to end testing? So what's what's your
Speaker 1: definition of integration testing? Yea, because without understanding that, it's
Speaker 1: hard to get Dan's toilet joke about uh integration testing.
Speaker 4: So yeah, testing terminology is totally broken. I think that
Speaker 4: if when you say end to end testing, or or
Speaker 4: even unit testing and integrationion testing, different people will understand
Speaker 4: different things. And for this reason, maya suggestion in every
Speaker 4: company in your company, name a very specific name for
Speaker 4: your test which is not integration and to take for example, Uh,
Speaker 4: just one example. In one of my customers, we used
Speaker 4: to test pages. We take a front and page we
Speaker 4: isolated and the test cope is every time one page.
Speaker 4: We call it page testing, and every everyone understands what
Speaker 4: page testing means. It's a test of a page. Integration
Speaker 4: tests just mean might mean three different things two different people.
Speaker 4: If we try somehow to clarify the integration test is.
Speaker 4: I think that the most common definition of it that
Speaker 4: we test the user journey in a thing. We test
Speaker 4: the wholes user journey in a single tier of the system,
Speaker 4: not and then tire system. So it might be the
Speaker 4: user visiting some front end but without stretching the entire system.
Speaker 4: It might be a user visit a call, coding some
Speaker 4: backend API and expecting your response. This is our examples
Speaker 4: for integration tests.
Speaker 5: So correct me if I'm wrong. It also includes, for example,
Speaker 5: testing components in isolation. So let's say I implemented a
Speaker 5: date picker component that the date range picking component, because
Speaker 5: you know you don't get that out of the box
Speaker 5: in the browser, and I want to verify that it's
Speaker 5: working correctly, and I can host it within like independently
Speaker 5: and basically simulate interactions with it. It's not end to
Speaker 5: end because it's not done in the context of the
Speaker 5: entire application. So it's not for example, if you think
Speaker 5: about I don't know, let's say some sort of hotel
Speaker 5: booking application, it's not done in the context of actually
Speaker 5: looking stay at a hotel. It's done in isolation, but
Speaker 5: it's still done at the level of actual user interface
Speaker 5: and interactions, not just invoking functions and checking return values.
Speaker 4: Exactly. You're in other words, you are testing the user
Speaker 4: experience with this in its almost real environment. There is
Speaker 4: a browser here, There is your code. There is like
Speaker 4: you have multiple layers here orchestrating together. You have that
Speaker 4: UI kid usually the UI kids that you're using, and
Speaker 4: then you have your code that trapping it, and you
Speaker 4: have us sometimes your state manager, and there is the browser.
Speaker 4: All the moving pieces that exist in production are playing
Speaker 4: together in this test. In this regard, it's integration.
Speaker 5: And if you're talking about non front and stuff, for
Speaker 5: example a node system, it might be testing a particular
Speaker 5: specific API call. Again not in the context of an
Speaker 5: actual complete user flow, and potentially even with certain other
Speaker 5: parts of the system being mocked like we said before,
Speaker 5: and not actually working with let's say you're working with
Speaker 5: various external services. You're not actually working with these services,
Speaker 5: you're mocking them, and you're just testing effectively your particular
Speaker 5: let's say micro service or particular aspect of a microservice
Speaker 5: in isolation.
Speaker 4: Yes, exactly what I observe is it works great for
Speaker 4: backing teams is testing your entire micro services is put
Speaker 4: the infrastructure on local doctor composed, test all the layer
Speaker 4: of the micro service. If you deploy it, you test it,
Speaker 4: your data access there, your business logic, your API, but
Speaker 4: only intercept calls to other services. Otherwise it becomes end
Speaker 4: to end with all the downsides that we have mentioned.
Speaker 5: Yeah, I'm currently actually doing exactly that, and the portrait
Speaker 5: that I'm working on. Being able to use a doctor
Speaker 5: composed to effectively recreate the entire system on your own
Speaker 5: particular on your local developer machine and then be able
Speaker 5: to dynamically deploy changes to the specific micro service that
Speaker 5: you're working on is effectively a godsend. It makes life
Speaker 5: so much easier when developing in such complex environments.
Speaker 4: Definitely, I mean's surprising how fast this test is. Like
Speaker 4: I think usually like a fifty proximately fifty test for
Speaker 4: micro service on a developer machine with real database last
Speaker 4: lesson twenty seconds. So yeah, it's a really efficient technique
Speaker 4: and maybe it's worth mentioning if we already discuss back end.
Speaker 4: There is now a build in test runners in o JS,
Speaker 4: mostly for back end, I think, and it's really gaining
Speaker 4: a lot of momentum.
Speaker 5: Yeah, it's it's interesting that it seems that between node
Speaker 5: implementing its own testing built in testing capabilities on the
Speaker 5: one hand, and v test on the other end, they're
Speaker 5: kind of cornering the testing market in a sense. And
Speaker 5: I recall, for example, seeing this post on x I
Speaker 5: think from KENC. Dodds talking about how happy is that
Speaker 5: the React testing library is no longer needed because effectively
Speaker 5: all this functionality is now built into v test.
Speaker 4: I think yes, And I think it's really interesting to
Speaker 4: see how people are contributing libraries and ideas together. So
Speaker 4: it reactesting Library was a library, but it was also
Speaker 4: a philosophy of how you test. Now the library is
Speaker 4: probably fading away or at least losing some momentum, but
Speaker 4: the concept that the concepts there, the techniques are being
Speaker 4: totally used in Vitas browser mode and in Playwright, and
Speaker 4: so many new testing framework are taking inspiration and building
Speaker 4: on this that It's very very interesting to see this
Speaker 4: evolving process.
Speaker 5: So in general, what would you say, is it still
Speaker 5: much more difficult to test the front end than the
Speaker 5: back end or are we achieving some sort of parity?
Speaker 4: M m yeah, I tell that I'd easily said that
Speaker 4: testing a back end is much much easier than testing
Speaker 4: a front end. Yeah. I mean, first, you can also
Speaker 4: judge it by the tooling. I means there are except
Speaker 4: that new test runners of NOJ that is actually bring
Speaker 4: less features. It's funny because the new test runners that
Speaker 4: a lot of back end teams are now using, it's
Speaker 4: us it brings much less testing features and what used
Speaker 4: to be like ingested people don't need even all the features,
Speaker 4: and there are very few like new tooling in the
Speaker 4: back and accept maybe contract testing tooling, which we will mention. However,
Speaker 4: you see that in the front and words there is
Speaker 4: a bloom and always constant change and struggling to build
Speaker 4: new tooling that are can catch up with the front
Speaker 4: and complexity so well.
Speaker 5: The fact that we actually need visual testing is an
Speaker 5: indication of how much more challenging front test and testing is.
Speaker 5: It's it's like almost like saying, let's let's test the
Speaker 5: bits flowing over some network connection and and basically try
Speaker 5: to analyze the system from that. If I'm using like
Speaker 5: silly analogy. So you were talking about you mentioned contract testing,
Speaker 5: Can you elaborate on that?
Speaker 4: Oh, definitely, I think that this is now one of
Speaker 4: the most interesting fields in testing in overall. I would
Speaker 4: even say that if in twenty twenty five you're not
Speaker 4: doing your your coding against API without any explicit contract,
Speaker 4: it shouldn't be an option on the table. First, let
Speaker 4: me explain there is. So we are all consuming API,
Speaker 4: whether front and to back and back and to backan
Speaker 4: and every system is distributed. Now, if as a consumer
Speaker 4: of an API, the payloads that I'm sending and receiving
Speaker 4: for me are just kind of unknown jason, some kind
Speaker 4: of Jason that I can control and predict, then imate
Speaker 4: risk of receiving a lot of breaking changes. So say
Speaker 4: for example, things work, but then my the APIs and
Speaker 4: un consuming change something. My test pass, but production will fail.
Speaker 4: And we are at this point we are really good
Speaker 4: at testing our components. But but the ocean, that ocean
Speaker 4: between components, we have much less testing ways and techniques
Speaker 4: to ensure the two different parties are aligned on the
Speaker 4: on the API between the two and now there is
Speaker 4: a there is a bloom of new techniques and tooling
Speaker 4: to cover exactly this as API consumer, how do I know?
Speaker 4: How do I get a guarantee that the payloads are
Speaker 4: changing and I should be prepared for that.
Speaker 3: So what are the solutions in this space?
Speaker 4: Yeah, so there is a spectrum of tooling and options. Uh,
Speaker 4: the simplest one just in a moder repot, just creates
Speaker 4: OD schemas, share them between the back end and the
Speaker 4: front end, and you get a solid protection, right, I mean,
Speaker 4: whenever the back end changes the schemas, your front and
Speaker 4: tests or it can be also your back end will
Speaker 4: fail because you have now you can generate typing from this.
Speaker 4: From these schemas, you can also do runtime validation and
Speaker 4: you're protected. But it doesn't cover a lot of frisk.
Speaker 4: On the other sound side of the spectrum, the more
Speaker 4: fancy tooling are mocking servers that will let you know
Speaker 4: that we'll provide you with a very sophisticated mechanism to
Speaker 4: synchronize the two parties. But there is the middle. I
Speaker 4: think that most of the solutions that are somewhere located
Speaker 4: in the middle between that are not too complex and
Speaker 4: not too simple and are not simplistic. Use the following.
Speaker 4: The API provider generates open API, usually it comes for free,
Speaker 4: and it somehow shared that open API with the consumer.
Speaker 4: Now the consumer all the consumers have tooling to generate
Speaker 4: both types, but also run time validation out of open API.
Speaker 4: So now as a fronten for example, whenever my back
Speaker 4: end changes the open API, if my types I say
Speaker 4: that's a new field was added, my code will generate
Speaker 4: types types based on this open API. And if I'm
Speaker 4: trying to access some fields it doesn't exist anymore or
Speaker 4: is the wrong type, I will get compile time or
Speaker 4: testing failure right away. So it's kind of me and
Speaker 4: back end are always aligned without spinning up a complex
Speaker 4: and fancy edit end environment.
Speaker 5: Yeah, but like you said, it almost kind of necessitates
Speaker 5: in many cases working in a mono repo. Otherwise, First
Speaker 5: of all, I hesitate to call it tests. I mean,
Speaker 5: it's it's basically you know, one of the benefits of
Speaker 5: using static typing is that you get certain bugs become
Speaker 5: impossible because of the type system. But I don't really
Speaker 5: consider it to be tests. It's basically that's it might
Speaker 5: You could call it another step in your build that
Speaker 5: might fail, but I hesitate to call it tests.
Speaker 3: Maybe it is. I don't know. That's an interesting philosophical question.
Speaker 4: Some of the fancy solutions are going beyond static typing.
Speaker 4: So what they do is that if you have an
Speaker 4: open API, it's not all about typing. Some kind of
Speaker 4: the assertions there are can be asserted only on run time. Say,
Speaker 4: for example, you have a rejects some of the fields
Speaker 4: type is a rejics. You can't assert this in typing Typescript. Also,
Speaker 4: Typescript is now adding some kind of tragic support. So
Speaker 4: what these tooling are doing during testing? Whenever you are
Speaker 4: sending to your mock some on payload, they are very
Speaker 4: fine whether the received testing payload is indeed conforming to
Speaker 4: the open API definition. So in that regard they can
Speaker 4: make the test fail if what you're using, the pedal
Speaker 4: you're using is not what the Beckend API defined. Of
Speaker 4: course for this you need like real testing. And maybe
Speaker 4: it's worth mentioning one work very cool features. I guess
Speaker 4: you both know ms W. It's a very popular JavaScript
Speaker 4: library for mocking intercepting HTP requests.
Speaker 2: No, sorry, don't.
Speaker 4: Oh okay, So let me introduce it. Ms w H
Speaker 4: is a library that allows by the way both also
Speaker 4: know jes also back in. It allows you to kind
Speaker 4: of define in your in your environment, kind of in
Speaker 4: kind of intercept network requests and say, hey, whenever I'm
Speaker 4: approaching another API, say the beckend, intercept it in browser.
Speaker 4: It's using by the way service workers, so you will
Speaker 4: see the request in the network tub and Chrome. But
Speaker 4: instead of going out outside your browser, MSW will return
Speaker 4: the response on behalf of your API, so you get
Speaker 4: a much more a much faster, and more predictable working environment. Now,
Speaker 4: ms W added a new feature this year, and we're
Speaker 4: discussing recent changes that instead of you defining what will
Speaker 4: be the API responses and you might be wrong there
Speaker 4: right what you think that there might be threefills in
Speaker 4: this payload, the beck end in fact, in production will
Speaker 4: return four or two. Ms W generates the responses from
Speaker 4: the beckend open API. So you provided, hey, this is
Speaker 4: what the API provided us the real world, the real
Speaker 4: scheme as it was generated, and it takes and generates
Speaker 4: responses based on this. So it's kind of you are
Speaker 4: you and the API that you consume are aligned, are
Speaker 4: always aligned? Does it make sense?
Speaker 3: Yes, as it does.
Speaker 1: Yeah, MSW stands from Mark Service Worker in case that
Speaker 1: wasn't clear already. So before we wrap up, is there
Speaker 1: anything else you wanted to talk about real quick that
Speaker 1: we have not yet covered in this world?
Speaker 4: Let me see, I've prepared a table of content here
Speaker 4: on the side. We can discuss a little bit more
Speaker 4: about testing with it. I also have we have covered
Speaker 4: this nothing significant syd with We have touched the measure
Speaker 4: points and advancement in testing, all right.
Speaker 5: So if before we I do have a final question though,
Speaker 5: in this context, So when you usually are when you're
Speaker 5: brought into a new project and and you want to
Speaker 5: before making any changes, I assume you want to make
Speaker 5: sure that you have good test coverage, because who wants
Speaker 5: to start making changes in a project before we have
Speaker 5: good testing coverage. What's the main thing that you're looking
Speaker 5: for in order to say this project has good test
Speaker 5: coverage versus another project that you might say this project
Speaker 5: does not have good test coverage.
Speaker 4: Yeah, that's that's the million dollar question. I'm even struggling
Speaker 4: to enter it. It's so it's so deep. But I
Speaker 4: think that I'm using two I'm using two aroistics for this.
Speaker 4: The first one is unfortunately not not in period. It's
Speaker 4: not measured. Uh, if people are moving, if people are
Speaker 4: really are having confidence to deploy fast, deploying deploying fast
Speaker 4: and just feeling confident to do it, you see it,
Speaker 4: I mean you you feel it, they trust are testing.
Speaker 4: That's I think the ultimate eventually the ultimate test. On
Speaker 4: top of this, I'm.
Speaker 5: It's literally just to just to pause you for a second,
Speaker 5: it's literally that subjective feeling that you test. You can
Speaker 5: ask people working on the project, how well do you
Speaker 5: trust your tests? If you if you make change and
Speaker 5: it makes its way all the way to to to
Speaker 5: being deployed to production, how secure do you feel about
Speaker 5: it working properly and not breaking any of the things
Speaker 5: or introducing any form of regression. It's it's essentially that
Speaker 5: that level of subjective feeling in the team.
Speaker 4: Yeah, that's the bottom line. I'm also using test coverage.
Speaker 4: I'm using branch coverage. Yeah, I know that it's not
Speaker 4: a perfect metric, but it's very simple metric and for
Speaker 4: the majority of teams, they are not like they're not
Speaker 4: fooling themselves. If if if system has a very high
Speaker 4: branch coverage. It's means that the testing are indeed testing
Speaker 4: most of that ninety coverage, not all of them, but
Speaker 4: a high percentage of this at least it tells me
Speaker 4: that most of the system areas are are trying to
Speaker 4: be tested. On top of this, I usually add some
Speaker 4: kind of mutation testing. So mutation testing means that it's
Speaker 4: a framework that plant bugs in your code, Like it
Speaker 4: can plant a bug in each and every line and
Speaker 4: then it runs your test and then true that they fail.
Speaker 4: And if yeah, now, because I mean it's it's an
Speaker 4: it's amazingly efficient technique to realize testing efficiency. But on
Speaker 4: the other end, it's really slow and cumbersome. So what
Speaker 4: I usually do I run it like I run it
Speaker 4: occasionally just to get a sense of what is the
Speaker 4: ratio between the COD coverage and the mutations. So in
Speaker 4: other words, if I see that I have COD coverage
Speaker 4: of ninety percent in a file, say I find file
Speaker 4: as ninety percent coverage and the mutation score is very low,
Speaker 4: it tells me that this is a nonsense coverage. You
Speaker 4: know that that's just visits amer coat off it. But
Speaker 4: it's not asserting one anything On the other hand, if
Speaker 4: I seek correlation between coverage and mutations in file, I
Speaker 4: know that this coverage is authentic. It's like trustworthy. So
Speaker 4: this is the empiric side of measuring that the test.
Speaker 3: Cool, Okay, thank you for that.
Speaker 5: Elucidation is that how you put elucidations.
Speaker 3: That's the word.
Speaker 1: I'll I'll google that word right after elucidate to explain
Speaker 1: something clearly is basically what it means.
Speaker 2: So that is the word of the day, elucidate already.
Speaker 1: So without move on the picks, picture that part of
Speaker 1: the show where we get to talk about anything we
Speaker 1: want to within reason of course, board, games, books, food, movie, tech,
Speaker 1: if you want to, I'll go first and my pick.
Speaker 1: I do have a pick before I get to the
Speaker 1: high point of the Dad jokes of the week, and
Speaker 1: it has to do with dad jokes. So at the
Speaker 1: end of our podcast episode that Dan and I recorded
Speaker 1: with Ryan Carneato and Tanner Lindsley, I found out something
Speaker 1: that I wasn't aware of that now Crosby, who was
Speaker 1: the founder of a G Grid, had died and apparently
Speaker 1: it is some type of helicopter accident.
Speaker 3: Well, it's to be fair, it's not new right.
Speaker 1: I know it is the first I'd found about it,
Speaker 1: you know. So yeah, that just tells you how out
Speaker 1: there in the news I am every day, and that
Speaker 1: brings back memories for me. So four years ago we
Speaker 1: did a Jobascript Jobber episode with Nile, myself and Ag
Speaker 1: and just a j O'Neal and Chuck and the Reason
Speaker 1: that I was. Episode five oh four came out in
Speaker 1: October of twenty twenty one, and this was one of
Speaker 1: my favorite episodes, as I mentioned before, because when it
Speaker 1: got to the end, Nile just jumped right in and
Speaker 1: throughout a whole string of geek dad jokes that I
Speaker 1: had to do with going to a no sequel bar
Speaker 1: and there's no table, So then he went to a
Speaker 1: sequel bar that had tables, but he couldn't join anybody,
Speaker 1: and it was awesome.
Speaker 2: I was giving him a standing ovation.
Speaker 1: So that's my pick of the for the week is
Speaker 1: you can find it on Top Endos episode five o
Speaker 1: four and if you want to look at the transcript
Speaker 1: or listen to it, it's it's one of my faves.
Speaker 1: So with that, we'll get to the dad jokes of
Speaker 1: the week. So question, how come nobody laugh at the
Speaker 1: joke about the fault DG eighteen.
Speaker 2: It was poor execution.
Speaker 3: That's good, all right.
Speaker 1: My wife told me the other day, I'm really getting
Speaker 1: sick of you over using contractions, and I said, it's
Speaker 1: what it is. And then, uh, someone threw a can
Speaker 1: of soda at me today or i'd say pop on
Speaker 1: the West coast.
Speaker 2: But I'm all right. It was a soft drink. And
Speaker 2: those are the dad jokes of.
Speaker 3: The week, and those who are definitely dad jokes.
Speaker 2: Yes they were.
Speaker 4: I'm embarrassed to admit that I understood two of the three.
Speaker 4: I promised to to rewatch that section and catch up.
Speaker 1: Okay, yeah, I can explain it. Yeah, it sort of
Speaker 1: kills a joke and you have to explain it.
Speaker 4: That is.
Speaker 2: Dan. What do you got for us?
Speaker 5: Okay, I've got a couple of things. So first of all,
Speaker 5: I posted it on x but I also want to
Speaker 5: shout it out a big thanks to THEO also known
Speaker 5: as THEO three GG, who puts out a lot of
Speaker 5: content online. I'm working on a project that involves Stripe
Speaker 5: integration for one of our services, and I've not worked
Speaker 5: with Stripe significantly, I think, ever, so I was kind
Speaker 5: of learning a lot about the stripe APIs and how
Speaker 5: it works, and they seem but Theo's video was essentially
Speaker 5: all the stripe gotchas that he encountered while working on
Speaker 5: various projects and how to overcome them, and it was very,
Speaker 5: very helpful. It came along at just the right time
Speaker 5: and undoubtedly saved me from a lot of pain down
Speaker 5: the line. So thank you for that, CEOs, Thank you
Speaker 5: for sharing this information. This is what sharing on the
Speaker 5: web is all about. So that's one thing I wanted
Speaker 5: to mention. Another is that we did this kind of
Speaker 5: watch along party at work. It's something that we tried
Speaker 5: for the first time and got a lot of good responses.
Speaker 5: It's great when you can have somebody at work giving
Speaker 5: a talk on a particular topic, but it's not always possible. Obviously,
Speaker 5: you may not have experts in how on everything. So
Speaker 5: what we actually did is we wanted to learn more
Speaker 5: about MCP and Jack Harrington, who we've had on the
Speaker 5: show a couple of times. He was also one of
Speaker 5: the hosts on the React podcast, and he created a
Speaker 5: series of videos about MCP that are just excellent. So
Speaker 5: we watched several of them in a row. They're actually
Speaker 5: fairly short each They're like ten to twenty minutes each
Speaker 5: and he explains things so well. So we basically watched
Speaker 5: a video and then had a brief discussion about it,
Speaker 5: and then watched the next video and so forth, and
Speaker 5: it was really great and I highly recommend this if
Speaker 5: you want to educate people at work. It's a great approach,
Speaker 5: I think. And the final thing I want to shout
Speaker 5: out is that I recently countered this video. This guy
Speaker 5: does videos about old hardware, and he released a video
Speaker 5: about a personal computer from the early eighties really called
Speaker 5: the Ti ninety nine four A. And the reason that
Speaker 5: this hit close to my heart is that that was
Speaker 5: my first personal computer when I was a kid. It
Speaker 5: was a very weird and wacky machine. And he literally
Speaker 5: kind of opened the screws and showed the insight of
Speaker 5: how that machine worked, to explain why it was so
Speaker 5: weird and wacky, and why it worked the way that
Speaker 5: it did, and what was good about it, and a
Speaker 5: lot of things that weren't so good about it. And
Speaker 5: you know, it brought back a lot of memories. So
Speaker 5: I'll share that link to that video. Let's just say
Speaker 5: that it was really interesting to probe for a system
Speaker 5: that had all of four.
Speaker 3: K of RAM.
Speaker 5: You know, in these days of gigabytes, you know, this
Speaker 5: is all we had.
Speaker 3: Yeah, that's it.
Speaker 5: Four kfram And within that four kf RAM, I implemented
Speaker 5: a Donkey Kong like game that had two screens. And
Speaker 5: I was like thirteen at the time, so yeah, it.
Speaker 4: Was which language did you use?
Speaker 3: I'm curious, basic, because that's what it had. It was.
Speaker 5: I joked that it simultaneously got me into programming and
Speaker 5: kind of also scarred me for life.
Speaker 3: So my first.
Speaker 1: Job in tech was doing tech support, and we were
Speaker 1: dealing with Win just three point one with our software,
Speaker 1: and I was constantly having to help users with memory
Speaker 1: issues and upper memory and lower memory and shifting things
Speaker 1: around so that things could run. And and then when
Speaker 1: I was ninety five came along and a lot of
Speaker 1: that went bye bye.
Speaker 5: I have a whole story about that, but we don't
Speaker 5: have the time. We could probably do an entire episode
Speaker 5: on reminiscing. So those would be my picture today.
Speaker 4: All right, Johanni, or to you, Yeah, I've recently found
Speaker 4: myself I'm interested in quality coffee, So I realized in
Speaker 4: mostly in the coffee story, So I really I always
Speaker 4: thought that like an expensive coffee is like expensive wine,
Speaker 4: you just pay for you know, for that brand or
Speaker 4: for that weird test. But then I when I started
Speaker 4: reading more and more and see videos about testing, I
Speaker 4: realized that like between the farm and your cap, they
Speaker 4: are like ten mistakes, like like dozens of mistakes. Most
Speaker 4: of them are intentional, intentional to just to just cut
Speaker 4: coast and make the coffee horrible. Take for example, in
Speaker 4: any commodity farms, when they when they pick the cherry,
Speaker 4: when they when they collect the cherry picks, some of
Speaker 4: them are already just mature and some are unriped, some
Speaker 4: are red, some are green. Uh so, but you know
Speaker 4: they have to be efficient, so so just take the
Speaker 4: entire tree down. You get coffee bins that are right
Speaker 4: unripe together, some are really sour, some are really really sweet.
Speaker 4: And and that's just one thing that the coffee coffee
Speaker 4: production is doing in order to bring your coffee with
Speaker 4: lower costs and more revenues for them, and really getting
Speaker 4: a great cup of coffee demands a lot of a
Speaker 4: lot of uh decisions and optimization all over the all
Speaker 4: over that process, and it's it's there's no point here,
Speaker 4: just a very fascinating journey that involves biology, nature people. Yeah.
Speaker 4: Other than that, I realized that we are getting more
Speaker 4: and more dependent on lms, right, I mean we're about
Speaker 4: to use it for ten percent off coding or maybe
Speaker 4: ninety percent. I mean it's objective, and I felt like
Speaker 4: it's too much of a black box for me. I
Speaker 4: can't understand the mechanic them. So say, for example, I'm
Speaker 4: providing it with fifteen instructions, it's respecting thirty. Why it
Speaker 4: fits inside the context within the Why did you ignore
Speaker 4: twenty of them? So I bought a book which is
Speaker 4: called I wanted to understand this box from inside. I
Speaker 4: bought a book that's called Building an LM from Scratch.
Speaker 4: It's just teach you build all the layers of an LM.
Speaker 4: Of course a very simplistic one, but you get idea
Speaker 4: of all the moving pieces. I'm now reading it, coding it,
Speaker 4: and I think that I, after processing four chapters, I
Speaker 4: can surely recommend it.
Speaker 2: Right, to go back to your first pick, I would.
Speaker 1: All I will say is that the term quality copy
Speaker 1: is an oxymoron, so there is no such thing, and
Speaker 1: I'll leave bit at that. So all right, Well, thank you,
Speaker 1: Johanni for joining us today and talk to you about testing.
Speaker 2: I appreciate it you coming here before we go.
Speaker 1: If people want to get hold of you and give
Speaker 1: you money and and do all that kind of stuff,
Speaker 1: where is the best place to track your genius?
Speaker 4: Thanks for mentioning this. Well, my gietime page has a
Speaker 4: contacts There is also goldberg Oni dot com.
Speaker 5: And you said that you work as a consultant, so
Speaker 5: I assume that you give assistance training and help organizations
Speaker 5: improve their testing and test coverage and quality of tests
Speaker 5: and whatnot.
Speaker 4: Yes, workshops ends on, ends on, and holding any any
Speaker 4: any kind of assistant and training.
Speaker 2: And that's it.
Speaker 1: Joannie Goldberg Goldberg Goldberg, Yohnnie excuse me? Alrighty and Yonie
Speaker 1: is y o n I just.
Speaker 4: Yeah or gita dot com slash Goldberg Yonnie.
Speaker 1: Okay, alrighty, Well that is it. Another thrilling episode is
Speaker 1: in the books. Thank you for joining us and we
Speaker 1: will talk to you next time on job script Jabber