Markus Oberlehner joins this week's episode alongside Cody and Steve. They dive into the world of testing and the importance of writing application tests. They share their journey from initially focusing on unit tests and component tests to realizing the need for comprehensive application tests that simulate real user interactions. They also provide valuable insights into the fear of sharing your work, the value of collaboration, and the importance of embracing imperfections. 

Steve (00:01.166)

Hello everybody, welcome back to Views on View. I am Steve Edwards, the host with the face of radio and the voice for being a mime, but as with every other week, I'm still your host. With me on my panel today, I have Mr. Cody Bontacue. How you doing, Cody?

 

Cody Bontecou (00:18.118)

Hey everyone, just took a quick trip over to Spain, so my background is looking a little different today, but happy to be here.

 

Steve (00:27.306)

Quick, define quick from Hawaii to Spain.

 

Cody Bontecou (00:31.066)

33 hours both each way.

 

Steve (00:33.53)

Okay, yeah, your definition of quick and my definition of quick I think differ slightly and then Today as our special guest we have mr. Marcus Oberlinner. How you doing Marcus?

 

Cody Bontecou (00:39.382)

Yep.

 

Markus (00:46.877)

Hello. I'm good. Actually, before we started recording, we were talking about the book and I just finished it. I wanted to say that, so I think that's a good start.

 

Steve (00:59.77)

Yes, always feel good. Yes, we will get into that book and its contents and details here shortly. Before we get going, Marcus, could you give us the intro about who you are, why you're famous, why people should give you money, et cetera?

 

Cody Bontecou (00:59.954)

Oh, congratulations.

 

Markus (01:15.789)

I don't know if I'm famous actually but I'm here so that's good enough for me. My name is Markus Oberlinner and you did a decent job with the last name. I think it worked quite well. It's Austrian actually. And yeah, it's important this differentiation for us but it's okay. Yeah, I'm...

 

Steve (01:27.166)

Thank you, thank you. Oh, it's Austrian, it's not German, excuse me.

 

Markus (01:40.877)

I'm a Vue guy basically, so I wrote a lot of blog articles for Vue.js stuff and recently I'm also doing a couple of conference talks also mostly about Vue.js. But more recently also a lot about testing, not only Vue.js but testing in general, testing web applications in general.

 

Steve (02:03.682)

Excellent. And then before we get started, sometimes I forget these people always drives me nuts. We'd like to welcome a student audience So how you doing audience?

 

Cody Bontecou (02:16.214)

I don't know if you clicked it.

 

Steve (02:17.758)

Thank you, thank you. They always add a lot to the show. It's always good to see them out there. Okay, so from here, we're gonna let Cody drive from here. We're gonna talk about testing in view, testing everybody's favorite subject.

 

Cody Bontecou (02:32.958)

Oh, yes. Okay. In fact, I do really enjoy testing. But I have many questions. And that is why we wanted to invite you on the show, Marcus. I know you've been writing this book for a while, and I've been subscribed to your sub stack. And in fact, shout out to Lachlan Miller, because I know he interacts with your content pretty often. And he's given me a big strong understanding of testing

 

Cody Bontecou (03:01.13)

And I was just like, yeah, I don't know if you want to tell us about your journey writing this book and like what you've learned, what's best practices. Like there's so many things specifically, you know, the testing triangle, how into component testing are you versus like traditional unit tests or end to end tests? Like it's such a big broad area.

 

Markus (03:23.777)

Yeah, there is a lot to unpack here. So maybe I start with the story about the book, how I got going. So I think two years ago from now, I thought writing a book would be an awesome idea because I don't have enough to do without writing a book beyond work and all that stuff. And yeah, I didn't.

 

Steve (03:50.142)

Plus everybody gets rich writing tech books, right?

 

Markus (03:52.553)

Yeah, definitely, definitely. Yeah, I will see, maybe. But I don't have my hopes up too high. But yeah, actually, I thought that I might finish it in a couple of months, you know, but yeah, time did go by and it took longer and longer. But yeah, as I said at the beginning, now I've just finished it and...

 

Steve (03:56.946)

That's what I've heard at least.

 

Markus (04:20.669)

Maybe, yeah, when is the book ever finished? Like I still have to do some proofreading and stuff like that. But yeah, two years basically was the journey and now it's finished. And I have to say that I learned a lot in the process. This is probably one of the most important things for me about writing in general. And also why I really enjoyed writing blog articles is that you learn so much from thinking about.

 

the stuff you write about deeper and exploring things you thought you know, but actually you didn't really fully understand yet.

 

Cody Bontecou (05:10.846)

I see your lips moving Steve, but I think you got your mute button on.

 

Steve (05:16.682)

I had a great speech going too, man. That was awesome. Let's try that again. So yeah, the old adage is that you know, if you want to learn something, teach it. Right? Because in order to be able to teach somebody else effectively, you have to know it yourself. So I think that goes without saying even though I did say it.

 

Markus (05:18.563)

Hahaha

 

Cody Bontecou (05:19.063)

Sorry. No.

 

Markus (05:35.953)

Yeah, that's definitely true.

 

Cody Bontecou (05:36.318)

Right. And so knowing what you know now, Marcus, would you tell yourself two years ago to write this book?

 

Markus (05:48.594)

I was thinking about it recently and I'm not quite sure, you know, because on the one hand I think I had a more rosy picture about how it would go, but on the other hand also all the things I learned and I'm really happy that I learned.

 

Markus (06:16.157)

I thought I want to write the book, why I want to write the book. I think those didn't really come true, those things, but a couple of other learnings I didn't expect and the experience itself of writing really long.

 

long coherent thing because writing blog articles is one thing but you know it's like maybe a thousand or two thousand words but writing a book it's a much bigger project and all the meta things I learned doing so I think at the end I would say yeah it was still worth it.

 

Cody Bontecou (06:58.75)

Oh, I'm sure. Do you think you'll write another book? And if you were, would this book be faster? You know, knowing what you know now with the whole meta side of it.

 

Markus (07:04.418)

Oh.

 

Markus (07:11.842)

Yeah, yeah. I think it would be faster. And on the question if I want to write another book, I think it's... Currently I'm in the phase of... No, I don't think so. But give me a week or two and probably I will think different about it. It's basically the same with conferences for me. Whenever I have a conference talk lined up...

 

Cody Bontecou (07:30.671)

Yeah.

 

Markus (07:39.625)

like a month or two months before I'm like, oh cool, I will be in this awesome location and speak to these awesome people. And then a week before the conference I'm like, oh why am I doing this to me? I will never speak at a conference again. And then a couple of weeks go by after the conference and yeah, I should write this CFP.

 

Cody Bontecou (08:02.722)

then there's right exact. So I am two days away from giving a talk at a conference. And so I'm very much in that, what am I doing? I just flew for 30 hours. Like, but yeah, we'll see. Hopefully, hopefully it's worth it. It's always worth it. Always meet great people and learn amazing things. But yeah, I am very excited for your book. Do you plan on doing a physical print or is this a?

 

Markus (08:09.534)

Yeah.

 

Markus (08:13.556)

Yeah.

 

Markus (08:21.99)

Yeah.

 

Markus (08:32.889)

I want to avoid it if I can, but maybe if there are many requests maybe I think twice about it. But currently I'm not planning to do it because from my own experience I like it more to have the digital version. I hope that for others it's the same, but let's see if there is demand for it maybe I think about it.

 

Cody Bontecou (08:58.586)

Yeah, for sure. Of course, the portability of ebooks is amazing, but I'm a sucker for physical books myself. But I understand that's, I'm sure, a whole other layer of complexity in terms of printing and distribution.

 

Markus (09:07.689)

Yeah.

 

Markus (09:17.199)

Exactly at dawn.

 

Steve (09:17.222)

Well, the problem that I've seen with written books, especially in the tech world, is how fast things change. I mean, you get a book out there, here's everything great, and boom, everything's changed. All of a sudden, your book is not as accurate, really, anymore. And that's the benefit of an e-book, obviously, is that it's, I'm guessing it's easier to update that and put out an updated version or something like that, and it's immediately available to download and look at versus a printed book. So.

 

Markus (09:22.89)

Yeah.

 

Steve (09:45.814)

Yeah, I'm like you, Cody. You know, I can really appreciate having a book here on my, you know, desk, you know, that I can look at and refer to and bookmark and that kind of stuff. But at the same time, you know, me with my panoply of screens here in my office, I can put a book on one, you know, and then do my coding on another or something like that. So they both have their benefits.

 

Markus (10:07.541)

Yeah, true.

 

Cody Bontecou (10:07.99)

Yep.

 

Markus (10:10.165)

But what you said about updating is definitely an important aspect of it, because I have a couple of deck books at home which basically were outdated at the time they were released or leaving the printing press basically. And also it's still testing, especially...

 

Steve (10:24.987)

Right.

 

Markus (10:32.569)

especially modern web applications, I think there is so much not yet really explored yet. So I think it's especially fast moving. So probably for cases like this, I think it makes sense to have a digital version. Because what I have to say, and for other books, for more durable books, like call it that way, I'm also in camp, a printed book, because just of the...

 

of the feeling of putting in your, how's it called?

 

put it away in your bookshelf, thank you very much, when you finished reading and seeing all the books that you actually read. It's definitely a better feeling if you also have printed books. But for technical books, I'm not too sure if it's worth it.

 

Cody Bontecou (11:08.879)

bookshelf.

 

Steve (11:30.546)

Yeah, I can look back in my bookshelf. You can sort of, you can't really see it here. My camera's not turned this way, but I have incredibly modern, up to date books like, uh, see PHP five, uh, learning jQuery, uh, Apache solar 1.4. If you know anything about solar, uh, you know, the, uh, O'Reilly HTML and X HTML, uh, pro get the first, the first pro get books. So

 

Cody Bontecou (11:31.068)

Cheers.

 

Markus (11:42.225)

Yeah.

 

Cody Bontecou (11:42.542)

Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha

 

Markus (11:56.616)

Classics.

 

Steve (12:00.038)

Yeah, they take up some great space on my bookshelf and look really good until you start looking at the titles and think, oh boy, he needs some new books.

 

Cody Bontecou (12:01.294)

Thanks for watching!

 

Markus (12:08.705)

Hehehehe

 

Cody Bontecou (12:10.823)

That is right. I'm sure they're being put to good use.

 

Steve (12:16.61)

I have one book that I call Bookzilla that was a book on Drupal 7 when Drupal 7 first came out and I was in that world. It's really great because it's about probably 3 or 4 inches high and elevates one of my computer monitors up so I have it at a better level.

 

Markus (12:32.357)

Hahaha

 

Cody Bontecou (12:37.552)

But your brain is stronger from reading that entire book. It was worth it.

 

Steve (12:42.054)

Yes, yes, I just, I look at it and sort of imagine myself lifting it with my thoughts and it makes my head stronger.

 

Markus (12:47.585)

Hehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehe

 

Cody Bontecou (12:48.642)

Oh no. Okay, well let's get into testing a little bit. I'd love to pick your brain a little bit Marcus. I don't know if you want to just, how is your book structured? How do you start introducing testing to your readers? Are you building off of fundamentals and scaling? Or is it more like, are you interested in this topic, go to this chapter?

 

Markus (13:14.585)

Yeah, so I moved a couple of chapters around a couple of times during writing the book. This is also something that's rather unexpected that you know you write something and then you reference it in a section.

 

further down and stuff like that. So as a side note this is something you don't expect when writing a book that you actually have to reorganize it constantly. But I settled on a structure where at the beginning I start with explaining my view on a couple of...

 

testing approaches. There are so many names or variants of how you can test your applications. People talk about end-to-end tests, about component tests, about unit tests, about integration tests, about all kinds of different testing approaches. Sometimes those are really different approaches and sometimes those are only different names for basically the same. So yeah, I start with

 

my view on those things and also with my definition of a couple of things. Because I decided to settle for my own definition for a couple of tests. Maybe it's... On the one hand, it's kind of risky, I think, to reinvent names for testing approaches. But on the other hand, things like end-to-end testing or integration testing.

 

Many people have different views on how an end-to-end test looks or how an integration test looks. So I thought maybe it's better to have my own vocabulary and don't have all this baggage. Maybe some people carry with them from previous experiences. So I decided to go with...

 

Markus (15:22.985)

calling the testing approach as end-to-end tests, application tests, component tests, and unit tests. So end-to-end tests for tests that really go end-to-end from the user interface to a database, for example, and application tests which only test the user interface and component tests which test little components and unit tests which test functions and classes and stuff like that. So this is...

 

the beginning of the book, so explaining the basics and clarifying my thoughts on things. And then we go into testing strategy and the most important principles that I think are important for writing good tests. Also recently I did a video about one of the following chapters which is about how to set up everything perfectly. So I called it the...

 

perfect test environment. And then step by step I go into much more detail about how to write good component tests for example and how to write good application tests. And I finish everything up with a chapter about practicing test-driven development and where we build a little shopping list application step by step, writing tests first and then the implementation.

 

This is basically the last and final chapter. And that's the basic structure of it.

 

Cody Bontecou (16:57.366)

Nice, yeah, that makes perfect sense. Yeah, I enjoy that. I understand, like you were saying, it's risky to redefine or set up your own definitions, but at the same time, that does kind of create a universal language within your book that is valuable. And that's interesting. And so I'm curious, I guess, I'm curious, I have like my own.

 

Markus (17:17.046)

circuit.

 

Cody Bontecou (17:27.486)

I'm curious what your opinion is about like component testing or really, I guess, what to test, what are the most essential tests to write and then where to go from there.

 

Markus (17:37.109)

Hmm. Yeah, yep.

 

Markus (17:43.969)

That's a very interesting question in two ways. Because first of all, that's one area where I basically changed my view completely from when I started writing the book to now. And secondly, it's also an essential question, I think, because one mistake I made...

 

when I started out with writing tests is that I wrote a lot of tests in every category. So basically I wrote a lot of unit tests, I wrote a lot of component tests and I also wrote a lot of end-to-end tests. And I was always of the opinion that you should focus most on...

 

component tests and unit tests because that's the general knowledge that you know those are the fastest types of tests and so you should focus on them and there is some truth to that but also if you think about it, they don't really give you a lot of confidence that your application actually does what it's supposed to do because you can you can have a component test for each and every one of your components

 

and still you hit the deploy button and everything breaks down when the user interacts with it. So that's why I now think that the most valuable tests are what I call in the book application tests, which basically are end-to-end tests that don't actually go to your services if you work with microservices but use, but mock third-party API requests and stuff like that.

 

test actual features from the perspective of a real user interacting with the application. So I advocate for mostly focusing or first focus on application tests. So write an application test for a new feature you want to write. And then if you feel the need, maybe write a component test or two.

 

Steve (19:49.798)

So before we get going any further, one thing I like to do is define terms. So we've mentioned a few different kinds of tests here, and then I've got a couple of things to say too. Can you tell me what the difference is between a component test and a unit test?

 

Cody Bontecou (19:50.299)

and

 

Markus (20:05.281)

here. That's also an interesting aspect because when I in the first iteration of my book I started calling both component tests and unit tests unit tests because my rationale was that a component test is basically a unit test for a component. This was my thinking but then I changed my mind a little bit because I thought that unit tests

 

Many people think that unit tests have to be very, very small. And I think that's maybe true for unit tests of functions and classes and stuff like that. But not so much for component tests. I think component tests don't need to be as small as possible, but can also be a little... Because you basically shouldn't mock...

 

any child components for example. And that was, that is what a lot of people, what a lot of people are doing is that they, when they do component tests, that they mock child components for example, because from their experience, from doing unit testing, they think it's the right thing to do. So I settled on using two different terms. So component test, testing a new component or some.

 

UI component and the unit test testing, for example, a function or a class or smaller bits or a JavaScript module.

 

Steve (21:37.41)

Or okay, so it's not necessarily listed, excuse me, limited to JavaScript. I mean, to me, the way I've always understood a unit test is it's a strictly code test, okay? There's no UI involved. There's no buttons, no browser or nothing. It's just you're running your code. You wanna test a specific portion of code that does a certain function. Maybe they go out and searches, right? And so you wanna test your code. Everything else you need, you mock, right? You create fake.

 

whatever, a fake API, fake UI, whatever, and then you run your code and see if it does what you do. Now considering that is a component test code only, or if it's UI, I mean, a view component is creating UI. I mean, unless you have like a non-rendering component, a view component is creating UI. So how do you specifically test a component when a component is part of a bigger picture on a page or a puzzle on a page?

 

Markus (22:32.393)

Hmm. Yeah. So I think about it that way that for a component has to be useful, the component has to include...

 

Markus (22:51.805)

a logic that's not only rendering something. Like usually the most simple UI component you can imagine, get some props and renders some HTML or virtual DOM object. But oftentimes we have components that are a little bit more complex than that. Maybe they do, they can transform some data or...

 

there are complex conditions in there. If this then emit event X when clicking there and if that then emit event Y when clicking here and so on. And whenever this is the case I think a component test makes sense and then a component test how I define it actually tests a UI element.

 

and interacting with the test interacts with the UI component like a real user would do, like clicking a button. And we also focus only on the public API of this component. So the HTML that is rendered or the virtual DOM object that is generated and

 

and the interactions that a user can do like clicking a button or entering some stuff, some text in an input field and stuff like that. But a component test is kind of a mix of two concerns. Like when we think about a unit test, you write the test from the perspective of a developer using for example a function or a class or something like that. But with a component test,

 

First of all, you look at it like a user interacting with a tiny bit of the UI, like the UI that's generated by this component. But you also look at it from the perspective of a developer using the component in their UI somewhere, because there are things that only the user can interact with, like the button and the HTML that is rendered.

 

Markus (25:08.425)

But there are also things like props and events that are emitted by the component, which are only interesting for other developers using the component. So yeah, so a component test is kind of, yeah, it's in between of end-to-end tests and unit tests, and it has features of both basically. Like you interact with it like a real user would do, but you also have some aspects that are only interesting for other developers using the component.

 

unit test.

 

Steve (25:40.978)

So in my day-to-day, I work with a pretty huge view app that uses Laravel on the back end, and we use Elasticsearch for a lot of our data. It's pretty large, and we use Laravel's front-end testing framework called Dusk. And if you're a PHP developer, it's nice because you write the test in PHP, even though it opens your browser and runs through everything. And so, you know...

 

for any new feature, always writing tests to go through and operate this, to log in, click this button, do you see this, do you see this, make your assertions and so on. Is it not a safe assumption to assume that if your end-to-end tests are working, then your backend code is working as well? If not, why?

 

Markus (26:28.329)

Yeah, that's a tricky question because there are multiple ways how you nowadays can structure your applications and your backend in particular. Like with Laravel, I really like the Laravel approach. And if you do it the Laravel way, they got you covered in most...

 

testing regards. So like with Dusk you mentioned it, you have end-to-end testing that really is tailored to the needs of a Laravel application. And with a Laravel application you typically have a more monolithic application where you have your database and everything in one unit. And in that case...

 

Steve (27:22.994)

No, that's not true. Just not to contradict, but no, you can, there's ways you can mix and match with other front ends. So in our case, it's Vue, and all we're using is REST APIs to communicate with Laravel. If we weren't using Laravel, we could use another, you know, backend that has another set of REST APIs. So Laravel can be monolithic in that you use Laravel, and then if you use blade templates, for instance,

 

Markus (27:42.11)

Yep.

 

Steve (27:52.971)

or their built-in templating language, but with things like inertia, which is something I'm a big fan of, even just REST APIs, it's not necessarily monolithic, it can just be your backend.

 

Markus (28:05.745)

Yeah, I was thinking about the term monolithic because I didn't want to use it because it was the first one that came to my mind. What I meant was that a typical level-well application is like you have your backend and your backend is communicating with the database and then you have a frontend which might be...

 

blade templates or it might be a React application or it might be a Vue application. But it's typically very close together and you don't have multiple services. So basically what I'm talking about is the differentiation between microservices and a traditional Laravel application. Because I focus on traditional because we also have at my company we have

 

more or less a microservices based system also built with Laravel, which make up the microservices. But the important piece here is, I think, where the database schema is located. So that's actually not in the book, but a topic I want to explore further after the book is written, that basically you have to think in two different modes. If you have control over your database,

 

What you want to test with, for example, with your dusk tests in Laravel is really the whole application also writing stuff to the database. And when you run your dusk tests, as you said, you basically also know that your backend works correctly because you test everything. But in a microservices environment, things become a little bit...

 

trickier or not only a little bit trickier, but much trickier actually, because then you can't do stuff like seed your database for some test cases. With Dusk you can seed your database with just the data you need for executing a particular test case and stuff like that. And with microservices it gets much more complicated to do testing in that way.

 

Markus (30:19.345)

I forgot what was the initial question that led us to this.

 

Steve (30:24.062)

Well, what I had asked you was if your end-to-end testing is working adequately and your testing is passing, then is it safe to assume that all your underlying code, in other words, what you would cover with unit testing, component tests, is sufficient and is that true or not and so why not? I think I can sort of answer that question on my own first in that it depends on how thorough your end-to-end tests are.

 

Markus (30:37.725)

Mm.

 

Steve (30:51.826)

I mean, you could write for all kinds of use cases, but if you miss a particular use case where an error is gonna show up, then you're not gonna catch it, obviously. But that's true for any testing. You could write all your unit tests and miss a piece of code that doesn't work. So, I mean, that sort of goes without saying, I guess.

 

Markus (31:04.184)

Yeah.

 

Markus (31:08.549)

Yeah, I think you're right. When you have an intent testing place for everything, assume we have an intent testing place for every feature, at least every important feature of our application, then we can assume that everything works correctly, our components and our backend and everything works smoothly. And that's basically the perfect world scenario. And in that case, when you still want

 

to write component tests is when they help you during the development phase, I think. So when you write on a complex piece of UI or when you work on a complex piece of UI or you work on some complex piece of logic, then still, even though you actually don't really need them to make sure everything works correctly when you deploy, they still often are helpful to...

 

during development to come up with a better design or in general aid during development to have faster feedback whether what you the code you just wrote works correctly or not.

 

Cody Bontecou (32:20.994)

Yeah, just to add onto that, I'm a big fan of that. I suppose it's test-driven development, TDD, where you do that. You create your spec file, and you just create a handful of it statements of essentially your to-dos of what you want this component to do, what you want this page to do, whatever it is you're trying to do. And yeah, you just start writing out the tests, or not even writing out the tests, just simply writing out that sentence of what you hope to someday achieve

 

this code that you're testing is a great way to keep me on track and lead development and be very confident with the code that I am writing as I'm writing it.

 

Markus (33:04.497)

Yeah, exactly. But you just said that it helps you to keep you on track. I think that's also not an obvious factor when practicing DDT.

 

It helps you stay focused and also sometimes it helps you to stay motivated because you know you get this quick feedback and you get this nice green output in your console whenever you write some code that passes the test. I think that's also a very helpful aspect of testing.

 

Cody Bontecou (33:37.05)

And it helps you just think through it as well, right? Just like, what do I actually, what am I trying to solve right now? Sounds easier said than done. But I do wanna just mention one thing that I believe is a key reason behind component tests is outside of just like traditional end to end is, when you're building like a third party library, a component library, you wanna have these individual pieces.

 

Markus (33:38.891)

Yep.

 

Markus (33:43.929)

Yeah. Yeah, yeah, true.

 

Cody Bontecou (34:06.294)

tested and well thought out as well. But I could be wrong. I'm not a library maintainer, but that's kind of my perspective. I assume that's a lot of where this benefit and innovation is taking place is more in like these library, the library side.

 

Markus (34:24.029)

Yeah, but one thing I want to add to this is that yes, I think it's very helpful for component libraries to have those component tests. I think this makes a lot of sense. Yet also there is some risk, I think, to overdoing it, like writing component tests for, for example, for a simple button and testing every...

 

every variant with every prop that the button can take and stuff like that. I think you have to be careful to not overdo it with components even in this use case.

 

Cody Bontecou (35:01.25)

Yeah, just checking off those green boxes can be addicting too, right? It makes you feel like you're doing something. It's like totally unnecessary. It's like just asserting true. You're just of course, it'll pass. This book. So.

 

Markus (35:05.701)

Yeah.

 

Markus (35:16.154)

There.

 

I'm guilty of that actually.

 

Cody Bontecou (35:23.23)

Totally. I think we all are.

 

Markus (35:25.421)

Yeah.

 

Cody Bontecou (35:29.924)

Does that answer your question, Steve? What are your thoughts there?

 

Steve (35:35.002)

Yeah, I mean, I don't think there's any, you know, one, one size fits all type of answer. A lot of it, as with any case, is going to depend on your application, how big, how small, um, you know, how it functions. It's just, I was just thinking in general, um, you know, uh, end to end versus individual pieces and how they fit together.

 

Cody Bontecou (36:00.722)

Yeah, no doubt. I personally lean on the end-to-end testing. It's kind of an easy way of testing, I guess. I don't know. I think with these modern Playwright and Cypress, it's really kind of easy to just automate and simulate what an actual user is going to be doing, which does give me a lot of confidence. Where

 

Steve (36:06.739)

I agree.

 

Markus (36:15.893)

Yeah.

 

Markus (36:22.463)

Yeah.

 

Markus (36:25.981)

Yeah, that's true.

 

Cody Bontecou (36:27.542)

Where I struggle with it though is when I rely on third party services such as like Stripe or OAuth login. I think that's when it starts to get a bit more complicated and I haven't found a good solution there outside of just mocking, I suppose.

 

Markus (36:51.014)

Yeah, that's also...

 

Steve (36:51.674)

Yeah, when those environments go down, it can hose you. We had a case the other day where we were using a service called Pusher, and Pusher was down the entire day. And so all of our tests were failing all day, and we sort of knew that. So that's any risk anytime you're depending upon an external service or application that you have no control over.

 

Markus (37:16.317)

Yeah, one thing, it's third party services are basically the worst dependency you can have for testing, but also on the other hand, you also can confidently mock them because you know, you don't really have control about them anyway, if they work or not. But that's...

 

gets a little bit more complicated as I said before with microservices where you want to make sure that your application works with your own microservices basically but still you have kind of the same problem some of the same problems that you also have with third-party services that you don't really have control over them because maybe some other team is responsible for this microservice and

 

If you want to test a particular use case, you maybe need to get some specific response from a microservice, a set microservice, but you can't really control it and stuff like that. That's when I think it... This is an area where we don't have really good tools and approaches yet, I think, because you can always mock those microservices and I think this is what most people are doing, but still...

 

you kind of lose some confidence you try to get with end-to-end tests typically.

 

Steve (38:38.986)

All right, so we've been, sorry, go ahead, Cody.

 

Cody Bontecou (38:39.118)

And those mocks, sorry, one thing Steve, I was just gonna say, and those mocks, mocking a microservice that an other team within your organization provides requires a good amount of communication to be able to generate a good mock, which in my experience has been harder, easier said than done.

 

Markus (39:02.677)

Yeah.

 

Steve (39:05.886)

So, let's talk about the perfect test environment. Is there such a thing and if so, what is it?

 

Markus (39:14.989)

Yeah, I try to build the perfect test environment. Of course, it's perfect. It's always something we only can strive to, but not really achieve. But at least I attempted to do it with my book. And what I say what makes the perfect test environment is that it enables us to...

 

follow the most important principles for testing. And for me, I have three important principles, or three principles that I think are important to really write maintainable tests and tests that are not flaky and in general, what I call good tests. And those principles are, first of all, we want to decouple our tests from the test framework.

 

We want to decouple our tests from implementation details and we also want to decouple our tests from the user interface. And I think decoupling from implementation details is something we all heard and we all, most of us who did some testing already know that we should write tests that are not tied to implementation details of our code. But the other two might be not that...

 

common knowledge or maybe even somewhat controversial. So I start with decoupling from the test framework. So this is one important aspect of the perfect test environment I try to set up that we don't use, for example, Playwright or Cypress directly, but we have a generic driver interface that we use to build.

 

or to write our tests. So whenever we want to switch test frameworks, we don't need to touch or change all of our tests, but we can write a new driver for the new test framework and then we can run all our tests in this new test framework without changing any test at all. And as an example, in the book, I do this with retest and playwright. And I do this because

 

Markus (41:37.701)

This shows what's really possible because usually one would think, yeah, there are tools like Playwright and Cypress, which run your tests in a real browser and with a real DOM and stuff like that. And then there are tools like Vtest and Jest and stuff like that, which you can use to write unit tests and maybe component tests, but not really those end-to-end tests or I call them application tests. But

 

In reality, when you have a single page application, you can basically render your whole application in a virtual DOM. The same way you do with single components when doing component testing. And using this driver setup, this generic driver setup, you can switch between running your tests in Playwright, so running your tests in a real browser, but taking some time because, you know, running a real browser has some overhead and the real DOM is not as fast as a virtual DOM in Node.js.

 

And you can switch between the real browser tests to running your tests in vTest in virtual DOM, which is very, very fast. So one talk I did, I think Jacob talked about this in the last podcast episode that was released. Yeah, I started the tests on the stage. I started the tests at the beginning running in Cypress and somewhere at the end of the talk.

 

the tests were still running and I started the same test suite in parallel in vtest and the vtest test suite finished in a couple of seconds while the Cypress tests were still running. So by using this driver interface, first of all you can swap out your test framework whenever you want, you know, because nowadays Playwright is more popular than Cypress for example and so you might decide to use Playwright instead of Cypress.

 

And if you use a driver, you can just do this. It maybe takes you an hour or two hours max, and you are done. All your tests run now in a different test framework. But you can also have the benefit of having two modes basically. If you want to have the guarantee that your tests work, or that your application works in a real browser, you can run your tests in Playwright, but it takes a while. But if you only want to have...

 

Markus (44:02.037)

quick feedback because maybe you did some major refactoring or something like that and you want to get very fast feedback you can run your test, a test for example and get the feedback in a couple of seconds this is the first aspect of the perfect test environment

 

Cody Bontecou (44:22.764)

Sorry, how do you control between these two environments? Are you just passing in a flag, I'm assuming?

 

Markus (44:31.761)

Yeah, so it's a little hacky how I do it, because there is no default or no standard way how you can easily do this. I tried a couple of things. I tried to do it with symlinking, like saying when I run the tests in vtest, I swap the driver file and use the vtest driver file, for example. And this worked, but it was not very elegant, I think. And...

 

The solution I go with now is to use resolve aliases. I use a resolve alias in the vtest config for example. So in the vtest config I say when I import this module with this name, then resolve it to the vtest driver file. And for playwright I specify it in a separate typescript config file that's only used by playwright.

 

So when I run the Playwright test, Playwright picks up this TypeScript configuration file and in there is also a resolve alias which then resolves the package to the Playwright driver.

 

Cody Bontecou (45:50.601)

So do you tend to run most of your tests in V-Test in your personal projects and then maybe do it once a day and playwright?

 

Markus (46:00.689)

Yeah, basically when I, so how I do it is that whenever I, as I said, I want this quick feedback because I changed, I did not change in a single component or something like that, but I changed some stuff that really where I have to change a lot of files throughout the whole application. Then I think it's the perfect use case to run all those tests in Vtest. But whenever

 

I work on a new feature or something like that. What I try to do is that I have Playwright open in watch mode, so that I automatically see the tests running whenever I make a change to my code or to my tests. So those are those two modes. So when I focus on one feature and I'm building a new feature or I make some big changes to a particular feature, then I try to...

 

I use the watch mode of Playwright so I can see the UI and have this visual feedback as well. But when I make more refactoring kind of changes throughout the whole application, then I use Vtest to get this quick feedback.

 

Cody Bontecou (47:12.518)

And I'm curious, so when you originally started writing this book, you were doing it in Cyprus, right? So is this a perfect test environment? Was this inspired by that change?

 

Markus (47:19.55)

Yep.

 

Markus (47:27.581)

Yeah, this change made it easy to change my mind and use Playwright. Because you know that the driver is the same, so I didn't have to re-write the tests and stuff like that. But it was the other way around. So I already had this driver interface and then I decided to make the change to Playwright. And the reason I chose...

 

So the reason I chose Cypress was because the user interface of Cypress, the UI mode of Cypress and the watch mode of Cypress, they were a lot better than what Playwright had to offer. And even though Playwright did make some improvements to their UI mode and also added the watch mode a couple of months ago, I would still say that the Cypress UI is better, but

 

Still, I think the Playwright UI is good enough for me. And Playwright is just a lot faster. And that's why I decided to make the switch to Playwright. Because I think having fast tests is very important.

 

Cody Bontecou (48:37.482)

Yeah, I mean, that's kind of the killer feature of Playwright is the speed. And I believe there's a handful of other features. I don't know if Cyprus supports iframes. I kind of lost track. It seems like Playwright has taken over in that realm.

 

Markus (48:48.074)

Yeah.

 

Markus (48:55.241)

Yeah, yeah, I think so too.

 

Steve (49:03.498)

So how does testing work in an agile environment? That's one point you listed here. And I guess the first thing to define would be agile. Since it first came into the lexicon and everybody's doing agile, we gotta do agile, scrum, agile, you know? And then people sort of figure out, well, agile is good for some organizations and maybe not for others. Waterfall ain't so bad in some cases.

 

Markus (49:03.674)

Yeah. Sorry.

 

Markus (49:09.662)

Oh yeah.

 

Markus (49:16.364)

Mm. Hehehe.

 

Markus (49:21.345)

Hehehehe

 

Steve (49:33.775)

First of all, how would you define agile? And second, how are the two linked together? How does testing work in an agile environment?

 

Markus (49:45.327)

How do I define Agile? I don't think it's synonymous with Scrum. I think a lot of people think Agile and mean Scrum. And I think that's not really how I would define Agile. I think those are not the same thing.

 

Steve (50:03.194)

Okay, I was just throwing terms out there. They may not necessarily be linked. You know, I've worked in agile environments with scrum masters and so on, and I'm like, okay, let's meet, talk about what we're doing. All right, we're good to go, thanks. I'm gonna go work.

 

Markus (50:05.542)

Yeah.

 

Markus (50:09.854)

Yeah!

 

Markus (50:13.701)

Yeah, of course, they often practice together, but I think you can do Agile without Scrum, but you can't do Scrum without Agile. I think that's how somebody put it in a video or so. So for the matter of the book, how I define Agile is, or not how I define Agile, but the aspects of Agile that are important for the book are...

 

working in iterations basically so you have a broad idea what you want to build like the typical user story or something like that and then Step by step you get more granular So yeah, you start out with the big idea and then you break it down And then in the book what I show is how you can take real user story

 

how to come up with the user story and then define acceptance criteria for the user story and then build upon those acceptance criteria to write your tests. And so how those two things, how working in an agile way and doing test driven development, how those play together really nicely. Because I think when the people, was it the Gang of Four or how were they called?

 

came up with the Agile method. They said one important aspect is technical excellence and Kent Beck I think he always had test-driven development in mind when he talked about Agile because

 

Cody Bontecou (51:41.742)

Thanks for watching!

 

Markus (51:58.165)

Having tests in place enables you, having the right kind of tests in place, let's put it that way, enable you to iterate and move fast and make changes without having the fear to break something. And I think it's important to say having the right kind of tests in place, because there are also tests which do the opposite and make it very hard to make changes.

 

Markus (52:28.137)

define Agile, I don't want to do the definition of Agile because I probably get it wrong. But I think in the way how it matters for the book is, like I said, working in iterations and breaking down user stories and acceptance criteria and how this can help you drive your testing strategy.

 

Steve (52:53.834)

Okay, so how does your perfect testing platform and everything we've been talking about work, or is there anything different in Agile, I guess, compared to another maybe non-Agile environment? I mean, to me, I've worked in multiple different types of workflows, and your app needs to work no matter how you're doing it. You need to test it, so what's the difference?

 

Markus (53:19.273)

Yeah.

 

Markus (53:23.517)

I think at the end of the day, when we look at the outcome, there probably is not too great of a difference in terms of how your tests look. Because also when working in a waterfall way, at some point you have specifications which you need to fulfill. And I think that's basically the outcome should be more or less the same regardless of how you work. You have...

 

some way to specify what your application needs to do. And then you have tests that ensure that it fulfills those criteria. And it's the same when working in an actual way. But what I focus on is how the process looks like. You have a user story and what then? Then come the acceptance criteria. Then you have acceptance criteria and then how do you translate those to tests? So this is the part that I focus on.

 

Cody Bontecou (54:22.718)

And that kind of goes right into that test driven development we were talking about, right? You can almost copy and paste the acceptance criteria into what you're expecting from the tests themselves.

 

Markus (54:35.069)

Yeah, exactly. Actually in the examples I did it like a one-to-one relationship from the acceptance criteria to the descriptions of the tests. In the real world it might be not that perfect, but in a book you can try to show what the perfect world could look like.

 

Cody Bontecou (54:58.571)

Right.

 

It's rare when a Jira ticket is that well-defined, right? We want this to happen, okay. That's neat though, so that's kind of how your book is structured. You're actually taking people through basically a real-world example of like...

 

Markus (55:04.669)

Yeah, yeah, exactly. Yeah.

 

Cody Bontecou (55:21.834)

almost like a document explaining the features or that we want built, turning that into tickets, extracting those tickets into like individual features, and turning that into tests and then features as well.

 

Markus (55:32.992)

Yeah.

 

Yeah, I tried to be very close to how I tried to make it clear how you can apply what you read in the book to your daily practice. I think to some degree I succeeded but I wanted to actually wanted to do more about of that. But yeah, that's the perfectionist in me I think. But it was the idea to you know, write a book that it's that you can really

 

Cody Bontecou (56:00.043)

hehe

 

Markus (56:06.246)

see how you can apply this in your daily practice or where you get inspired how you can improve your workflows to introduce testosterone development.

 

Cody Bontecou (56:17.878)

Yeah, I think that's actually a beautiful way of presenting that idea that I've never heard anybody talk about before. That is a very real way of actually writing tests. Most people, here's your function, now write a test for it. All right, next. It's never that simple, right? So I think there's always a gap while learning how to write proper tests.

 

Markus (56:39.683)

Yeah.

 

Markus (56:45.027)

Yeah.

 

Cody Bontecou (56:46.566)

especially front end tests. I think front end tests can get very cluttered, very difficult to test parts of the front end.

 

Markus (56:54.741)

Yeah. And what you hinted at, I think it's a hard problem for like writing blog articles and books and stuff like that. That, you know, you basically you have to show the most minimal examples. And sometimes it's hard for people to really translate this in a real application because they think like, yeah.

 

showing this very straight forward simple example. It's easy to write this for this or write the code like that. But in my real world application things are messy and stuff like that. But I really try my best to work around this a little bit. But it's hard actually because you know if you write a book with messy code then nobody understands it anymore.

 

Steve (57:43.05)

I'm sorry.

 

Cody Bontecou (57:44.658)

it's that, what's that meme where it's like the four panels and it's like how to draw an owl. And the first square is a circle, the second square is like three circles, and then the third is a perfect owl. And that is kind of the way it's presented. But, because otherwise it's, you're writing a textbook for a college course, depending on how in depth you want to go.

 

Markus (57:49.99)

Yeah.

 

Cody Bontecou (58:06.034)

I do think, I want to say it's refactoring. I want to say that was part of the gang of four, Martin Fowler wrote it. But I do remember that was the very first chapter, like 20 pages are just reading through a program before it's refactored and then after it's refactored. And it's kind of hard to get through at times, but it's also written in Java, which doesn't help.

 

Cody Bontecou (58:37.409)

Um.

 

Steve (58:37.626)

Judging by my recruiter emails, Java and JavaScript are the same thing.

 

Markus (58:41.445)

That was true.

 

Cody Bontecou (58:41.698)

Yeah. Right. So tell us a bit about your imposter syndrome. What's going on there? Obviously, from my point of view, you have so much knowledge to share. But did you not feel that way?

 

Markus (58:50.665)

Hehehe

 

Markus (59:02.949)

Yeah, you know, it varies. Sometimes there are those moments where you think, oh yeah, I'm the smartest guy that ever walked on this planet. But those are rare. Yeah, it's very rare for me too. But mostly it's like, you know, you... If you put your stuff all share in the world, it's kind of frightening because there are so many eyes on you who can judge you. But...

 

Steve (59:13.21)

I've never had that problem.

 

Markus (59:33.065)

But still I think it's important in two ways. I think it's important in two ways. First of all, if you want to learn more, I think you have to share what you know or what you think to know. Because it's also a good thing that people challenge you and it's also a good thing to have the pressure on you that you actually have to deliver something decent. Because...

 

If you plan to release something, at least you know you have to do more than the bare minimum. And yeah, with poster syndrome it's like every time I release a new chapter of the book or I write something, or I create a video for example, then I think to myself, oh yeah, that's just not good enough. There are people who have much more experience in this or that. And why do I even write the book?

 

And the thing is, I think it's true, you know, because there are people who know more about a particular aspect of this or that. And you always have to remind yourself, first of all, you don't have to write, you don't need to write a book who is the best book in every regard, because that's basically impossible. And also there is a lot of worth in...

 

combining multiple concepts. And then this is the area where it is like, yeah, there are people who know a lot more about unit testing, for example, and there are people who know a lot more about writing a particular style of end-to-end tests for an architecture with microservices or stuff like that. So there are always people who know more about one area. But if you combine all the things, you know,

 

but different kinds of tests and bring them together in a way that adds value, then I think it's still... I always have to remind myself that there is a lot of value in doing this and that you don't need to write the perfect book on everything and that it is okay to have... that there are some flaws. And also, at the end of the day, it's all, as we know,

 

Markus (01:01:59.101)

it always depends, you know, because for one team the approach I describe in the book might be perfectly right, but for another team who have a completely different experience, for them it might be wrong and I think, yeah, that's okay, that's okay too.

 

Steve (01:02:17.49)

Well, I think there's a flip side to what you're talking about as well. And, you know, I speak after a bidding, having been an open source for 18 years now, um, is that, yeah, there's pressure. There's people, there are people that will be jerks, you know, whether it's in a GitHub issue, whether it's in some sort of chat room, I'm dating myself. When I say going back to IRC chat, when that was the way to, to chat. Um, there are people who jerks you idiot. What do you think of doing this? You know, but on the flip side.

 

There are a lot of people that will say one, hey, this is cool, but you could improve this. They'll give you the perspective that maybe you as one person don't have. Two, there are people that will say, dang, I was thinking about doing the same thing. I'm glad somebody else, it's not just me who has these questions or is wondering how to do this. And they'll be willing to help you out. So there's the good with the bad. I think the term I've heard used is developing in the open. You're...

 

doing it, you're putting it out there. You know, you don't necessarily have to go to the extent of Twitch streaming, you know, where people are actually watching you type in Google for terms that you've forgotten that you think every other developer never forgets. You know, that kind of stuff too. You don't have to go to that extent, but just putting an open repo out there and saying, hey, this is what I'm doing. My experience has been, you know, if I see somebody that's doing something, oh, that's cool, I was thinking of doing the same thing. Or I've...

 

Markus (01:03:28.633)

I tried this as well.

 

Steve (01:03:44.722)

I've had feedback myself where I can remember in my early Drupal days, I saw somebody do a video about doing this and I created what's called a module, WordPress, you call it a plugin, that sort of encapsulated everything and the feedback was like, oh, this is cool, I'm gonna use this, I've been wondering how to do this too. So, I guess it just depends on your particular situation, but there's the pressure, it's probably more self-imposed pressure that you put on yourself of having to be perfect.

 

Markus (01:04:11.017)

Hmm.

 

Steve (01:04:14.022)

versus the pressure that says screw it, I'm gonna put this out there if you like it, use it if you don't, don't use it. And you'll get a lot of good feedback because people admire someone that's willing to get past that fear of public speaking, of being out in the public and say, hey, I like this. And I'll give an example. And this is sorta related. Number of years ago, I got hired to do a job I'd really wanted to do, which was firefighting. And I got hired as a professional firefighter.

 

And I had a fellow employee right before I left where I was at. I was in a copy, or the break room one day, and there was a lady, and I knew who she was, didn't know her, and she said something to me about what I was doing and said, doing what you're doing will probably inspire other people to follow their dreams as well. And I was just blown away. I was thinking, you know, here I am just sort of.

 

Markus (01:05:08.618)

Hehehe

 

Steve (01:05:10.686)

doing my thing and getting in my training and doing all this stuff. And here all these other people are seeing it and inspiring them and I had no clue, you know, that I was doing that. So I dare say that, you know, taking this risk and putting yourself out there like that is probably an inspiration to other people too. One, that you're providing some really good information that they could use and two, it's like, hey, this guy's putting stuff out there, maybe I should do the same thing.

 

Markus (01:05:40.07)

Yeah, that's definitely true. And one thing I always try to remember is, whenever, especially for conference talks, is that everybody in the audience, or maybe not everybody, but most of the people in the audience are your fans, you know, at least in this moment. Not, they are not the fans, like the group is of rock stars, but at this moment when you are standing on the stage, they are like, yeah, they want you to do well, you know, they don't want...

 

that you fail or even if you fail in some way, then it's not like they think about you in that you are a failure, but actually it's, you know, everyone who goes to a conference want to share ideas and connect with people and that's especially true for the speakers.

 

Steve (01:06:31.818)

Cool. All right, so we're getting a little long here, so we need to move on to picks. But before we do that, is there anything else you want to, any shameless plugs to put out there? Where are you on your book? You said you finished writing it. I assume that means it's not out the door yet. So what do you have left to do?

 

Markus (01:06:51.537)

Yeah, I finished writing it and people can already pre-order it. What I still need to do is to make a couple of videos, because I think especially with DDD, with Destream Development, it's good to see somebody actually practicing it. So yeah, that's still open. I will do a couple of videos which will be added to the book. But yeah, people can already pre-order it.

 

goodviewtest.com I think is the correct address. And yeah, and also I have a couple of shameless plugs. So I just started to be more active on LinkedIn because you know, Twitter or X is kind of shaky nowadays. So yeah, check out my LinkedIn profile if you want. And also, yeah, I also started to do workshops. So if your company is interested.

 

Steve (01:07:21.586)

Yes. Right.

 

Steve (01:07:28.586)

Go for it.

 

Markus (01:07:49.077)

get in contact with me.

 

Steve (01:07:50.694)

And you also have a substack, right?

 

Markus (01:07:53.265)

Yeah, exactly. For the book I also have a sub stack where people could read the book while I was writing it. Now it's basically finished, but still I will release some new stuff on the sub stack as well. And everybody who subscribes to the sub stack will also get the book. So you can't do anything wrong if you subscribe for the sub stack as well. Oh, I think it's goodvue-tests.substack.com.

 

Steve (01:08:15.026)

What is the URL for that?

 

Steve (01:08:22.994)

Yep, okay, and we'll have all these links in the show notes for sure. So, all right. All right. Well, thanks for coming on Marcus and talking about view testing. I know that generally, you know, when I've had conversations about testing, they tend to be pretty generic, so it's always nice to hear something that's, that's more view specific for sure. All right. So PICS, PICS is a part of the show where we get to talk about anything we want. Well, within reason, of course.

 

Markus (01:08:23.392)

That is it.

 

Markus (01:08:27.878)

Awesome.

 

Cody Bontecou (01:08:30.621)

you

 

Markus (01:08:42.781)

Yeah, thanks for having me.

 

Cody Bontecou (01:08:44.578)

there.

 

Markus (01:08:52.74)

Hehehe

 

Steve (01:08:53.19)

We don't want to be subpoenaed or sued by the FCC or something. But anyway, I will go first. First thing I'm gonna pick before I get to the high point of my episodes, which are the dad jokes of the week. There's a new show on Netflix and I referenced it a couple weeks ago when I was looking for it and it wasn't out yet and I talked about a show with Sasha Baron Cohen called The Spy. This one is called Spy Ops.

 

and it's on Netflix and the first season has eight episodes and it's true stories about true things that have happened over the years and they're stories from different agencies. So the first episode talks about the CIA and Operation Jawbreaker, which is when they first went in Afghanistan right after the 9-11 attacks. I skipped the second episode, but the third one is a really famous spy story.

 

with MI6, the British Intelligence Service, and how they got a spy named Oleg, I think it's Gordievsky, out of Moscow from under the eye of the KGB. It's a famous story, but some of the details of the story are fascinating, really interesting. And then the next two episodes I really want to watch are the ones about Mossad and how they went after the killers from the Black September killings of the Israeli athletes in the Olympics in, I want to say, 19...

 

72, 72 Munich was where that happened. So but it's fascinating stories for sure really great details So the dad jokes of the week. These are as I mentioned before the high point I get you wouldn't believe the The requests I get from people like will you stop doing them? I'm kidding So very short one I actually come from a family I don't know if I've mentioned this before

 

Markus (01:10:30.025)

you

 

Steve (01:10:47.167)

of magicians and as a result I have two half sisters.

 

Markus (01:10:53.309)

Hehehehe

 

Steve (01:10:55.982)

Right, you know the code to you where they cut them in half. Anyway, so I moved a little while ago and I actually moved into, I figured this would save on air conditioning bills and I moved into a new igloo. And my friends were like, hey, that's awesome. And they threw me a surprise house warming party. Now I'm homeless.

 

Cody Bontecou (01:10:58.968)

Yeah, yeah, yeah.

 

Steve (01:11:17.978)

Right? And then finally, the other day I went to my doctor and he told me that I have high blood pressure and short-term memory loss. I'm just glad I don't have high blood pressure.

 

Steve (01:11:37.162)

All right, so Cody, your turn. What do you have for us for picks?

 

Cody Bontecou (01:11:41.318)

Oh Steve, I don't know if I can top that, but I'll try my best.

 

Steve (01:11:43.826)

Well, you know, it's one of those things that, you know, that people always say to you always want to try and never give up, but in your case, you're right. You probably really can't. So that's good.

 

Cody Bontecou (01:11:50.89)

Right. Yeah, right. No, I, um, let's see here. So I believe my pick last week was, um, cursor, the cursor browser. And I just wanted to reiterate that I love the cursor browser or cursor ID.

 

Steve (01:12:02.292)

Yes.

 

Cody Bontecou (01:12:08.578)

In fact, I actually just subscribed to the paid plan and hooked in my chat GPT for API key. And it like coding, the coding experience has is like, it's changing right before our eyes. Like, in fact, I was reading a newsletter, I think it was from the pragmatic programmer, it could be somebody else. But I guess, I think his name is Larry Ellison. He's the head of Oracle.

 

Steve (01:12:35.529)

Yes.

 

Cody Bontecou (01:12:36.766)

just made an announcement how most of like Oracle's code is being produced through code generation as well, which I just thought was like very powerful because that's kind of how like the last couple weeks I've been feeling like I'm almost having this just dialogue experience with my terminal window and it's just like generating if I hit a bug I can read discuss this bug with my IDE and it kind of gives me like this entire document experience of

 

of like why this code is being generated and I'm learning a lot while utilizing it. So that's, I don't know, I just wanted to reiterate, absolutely huge fan of that. And number two pick actually is, you know, I'm giving a presentation soon as well and somebody posted on Twitter recently of how they do their slides using Figma.

 

And if you're not aware of Figma, it's just like kind of the hot...

 

kind of like design tool right now, similar to like Photoshop, kind of a bit more basic, easy to use. And it totally just like, I don't know why I never thought about it, but it's so nice to just use a design tool to build out your slides. Instead of like using something like PowerPoint where you kind of like the text doesn't ever really want to go where you want it to go, or you know, maybe you want to throw in like a little iPhone picture, like something of that nature, like just use like Figma, it's incredibly easy.

 

and the spacing, everything is perfect. So obviously Figma's pretty old news at this point, but there's new fun ways of using it.

 

Markus (01:14:10.849)

Thanks for watching!

 

Steve (01:14:18.794)

You know, before we get to Mark, because I'll say a couple of things. One, you were talking about conversing with your terminal, so to speak. That would be interesting, because my conversations with the terminal are usually like, what the heck? And what are you doing? What does that say? You know, so to ha-

 

Markus (01:14:29.941)

Hehehe

 

Cody Bontecou (01:14:33.694)

And now you can save that and it'll respond. No, it'll be, I apologize for the confusion, you know, and I'll just explain it. It's amazing. Yeah. Yep.

 

Markus (01:14:36.35)

Hehehe

 

Steve (01:14:37.293)

Right. And it'll respond with, you dummy, here's your excuse, here's your mistake. Right.

 

Steve (01:14:47.802)

It's polite, right? It's polite AI, right? Yeah, we, you know, Figma's been interesting to watch over the past few months because they got bought out by what, 20 bazillion? By Adobe. And I know a lot of people, as soon as they heard Adobe was buying it, said, okay, forget it, I'm moving on to something else. It's just saying, we just brought in a UI person, a designer, to help manage our app. And so...

 

Cody Bontecou (01:14:58.05)

Yeah, from Adobe.

 

Steve (01:15:15.506)

Over the past few days, I've been working with him on some designs that I need to implement. And it's got some really cool functionality because what he'll do is he can put a prototype out there or his forms, and then I can sign online and click his icon. And as he zooms around, looks at the different things, I automatically follow him, right? There's all kinds of really cool interactivity features that, you know, co-developing, however you want to call them.

 

Cody Bontecou (01:15:21.142)

Mm-hmm.

 

Cody Bontecou (01:15:27.246)

Thanks for watching!

 

Steve (01:15:41.454)

features that are really pretty cool. So yeah, my experience, what I've seen so far, I certainly like it.

 

Cody Bontecou (01:15:47.646)

And one other thing too is if the designer uses it, I'm not gonna say properly, but I guess in the way that Figma kind of developed it for, is it'll transition to Flexbox and CSS code very easily.

 

So if they use the feature called auto layout, it'll actually, the way that they design it is basically one-to-one with Flex, CSS Flexbox and everything revolving around Flexbox, which makes life as a programmer very nice. Yeah.

 

Steve (01:16:17.982)

Right.

 

Steve (01:16:27.622)

Alrighty Marcus, do you have any picks for us?

 

Markus (01:16:30.873)

Yeah, so I was thinking about it and I think that the best pick I have is recently I got myself a LEGO set again. So a lot of nostalgia building a nice LEGO castle and it's a really big one. Actually I shouldn't say LEGO I think because it's not really LEGO. You know it's there are a lot of other companies nowadays having all those brick things and yeah I really enjoy it because

 

Steve (01:16:39.434)

Woohoo!

 

Markus (01:17:01.058)

It's relaxing after a long day. You can sit there, watch something nice and build a Lego castle. It's nice.

 

Steve (01:17:10.11)

Yeah, my son is 12 and he's a real big, he's real big into Legos. We have my older son, who's now 20, when he was growing up, he had bought a number of different sets. You know, like he has this one, was it Millennium Falcon, Millennium Falcon or TIE Fighter, one of the two from Star Wars. And it was awesome when it put together, but he let it fall apart. And so now all these old sets, they came as sets. We have just.

 

buckets of Lego pieces all over the place. And my wife categorized them by color and size and stuff. And it's really cool. So you can still build some cool stuff. But anyway, his goal, his job goal as of right now is to work for Lego because he likes using Lego so much. So he's got the mind to do it for sure. So it'll be interesting to see if he does. So, all right.

 

Cody Bontecou (01:17:57.438)

That's probably a very fun company to work for. I imagine it's innovative.

 

Steve (01:18:00.414)

Sure. Yeah.

 

Yeah, I guess it depends on what you get to do. If you're the one that are making bricks or something like that, maybe not so fun, but if you get to be one of the creative type people, you know, and come up with designs and.

 

Markus (01:18:08.181)

Hehehe

 

Cody Bontecou (01:18:13.259)

Well, material science, they probably have a lot of material scientists creating new plastics.

 

Steve (01:18:15.97)

Oh yeah, absolutely. Yeah, for sure. For sure. So, all right, well thank you Marcus for coming on the show and talking about view testing. It's been very enlightening for sure. And before we sign off, I'd like to also thank the Studer audience for coming again today.

 

Yes, yes, thank you, thank you.

 

Steve (01:18:43.526)

If you really want to be in the studio audience, you can buy tickets online at views on view.com slash tickets. Not really, I'm just kidding. So with that, we'll wrap it up. Say adios and we'll talk to you next time.

 

Cody Bontecou (01:18:57.349)

See you later.

 

Markus (01:18:58.601)

See you.