Speaker 1: How'd you like to listen to dot NetRocks with no ads?
Speaker 2: Easy?
Speaker 1: Become a patron for just five dollars a month. You
Speaker 1: get access to a private RSS feed where all the
Speaker 1: shows have no ads. Twenty dollars a month will get
Speaker 1: you that and a special dot NetRocks patron mug. Sign
Speaker 1: up now at Patreon dot dot NetRocks dot com. Hey
Speaker 1: guess what, it's dot net rocks all over again. I'm
Speaker 1: Carl Franklin, an amateur camp here for your geeking out
Speaker 1: and you know, all that pleasure. If you're dot NetRocks pleasure,
Speaker 1: I hope you're having a good week.
Speaker 2: We are.
Speaker 1: We're getting ready to head to Orlando for dev Intersection,
Speaker 1: which should be going on.
Speaker 2: Yeah, yeah, this show will come out, This show will go,
Speaker 2: Will we go? Will be on when we're in Orlando.
Speaker 1: Right right now, we're probably up on the stage giving
Speaker 1: prizes away.
Speaker 2: Or doing something silly, which we are prone to doing.
Speaker 1: Yeah, to do well. We've got a lot of interest
Speaker 1: stuff to get through. So let's talk about nineteen seventy one.
Speaker 2: This is the all right you begin friend, because it's
Speaker 2: a big year. It's a big year. So let's see.
Speaker 1: I'm going to talk about some of the cultural stuff
Speaker 1: like the rock bands formed in nineteen seventy one include
Speaker 1: The Eagles, Queen fog Hat, New York Dolls, and Roxy Music.
Speaker 1: Radio and TV advertisements for cigarettes were banned in the USA.
Speaker 2: Yeah.
Speaker 1: At the beginning of that, Rolls Royce went bankrupt again. Yeah,
Speaker 1: the first ever email.
Speaker 2: Was sent up. I got a whole piece on that
Speaker 2: quirty IOP or something like that or test one two three,
Speaker 2: he doesn't remember.
Speaker 1: Yeah. The Nastac made its debut on Wall Street. Evil
Speaker 1: Knievel set a world record. I can't remember if he
Speaker 1: actually crashed or not, but he probably did. That was
Speaker 1: his stick. Hey watch this hold my beer boom set
Speaker 1: a record, but I broke every bone in my body.
Speaker 1: Ed Sullivan Show aired its last episode.
Speaker 2: End of an era.
Speaker 1: The New York Times started publishing The Pentagon Papers.
Speaker 2: Jim Morrison died. Yeah. Yeah, Tormented soul, Tormented soul. Yeah.
Speaker 1: Four countries gained independence Bangladesh, Baja Rain, Qatar, and the
Speaker 1: United Arab Emirates. China was admitted the General Assembly at
Speaker 1: the United Nations. M you're going to talk about that.
Speaker 1: Let's see. Oh, Charles Manson and three of his followers
Speaker 1: were convicted. Starbucks opened their first store. Yeah, I mean
Speaker 1: became president of Uganda. Well, Disney World opened in Florida,
Speaker 1: and there's so many more, but I'm going to pass
Speaker 1: the baton over to you, my friend. What happened in
Speaker 1: science and space? Let's do space First.
Speaker 2: Fourteen and PAULA fifteen are both in nineteen seventy one,
Speaker 2: and paul Of fourteen was the last of the original missions.
Speaker 2: That's Alan Shepard was the commander on it. It's the
Speaker 2: first American into space on Mercury. And of course he
Speaker 2: was a big golfer, so he brought a golf club
Speaker 2: and whacked a ball on the Moon. That ball has
Speaker 2: not been found. That kind of went far. It's been somewhere,
Speaker 2: went somewhere. PAULA fifteen was the first of the extended missions,
Speaker 2: so doubling the time on the Moon, plus when they
Speaker 2: introduced the rover so they were able to travel a
Speaker 2: lot farther on the Soviet side. Having lost the race
Speaker 2: to the Moon, they began on space stations and in
Speaker 2: nineteen seventy one lifted off with Salute one, only designed
Speaker 2: to function for six months, so it went up in
Speaker 2: April was deorbity in October. There were only two missions
Speaker 2: to it, so used ten soft docked but couldn't hard dock,
Speaker 2: so ultimately, after a few hours they had to give
Speaker 2: up and re enter, which unforture and the Soyu's eleven
Speaker 2: successfully docked and the crew spent twenty three days on
Speaker 2: the mission doing a bunch of experiments, and unfortunately on
Speaker 2: re entry the capsule depressurized and all three were assixiated,
Speaker 2: the first and only time that we actually had a
Speaker 2: crew die above the Carmen line versus been other astronauts
Speaker 2: lost at other times, but Georgie de belfe Ski, Vladislav Volkov,
Speaker 2: and Victor Patsayev were found dead in the capsule after
Speaker 2: re entry. But I would say that the Salute one
Speaker 2: is the core designed for every space station going forward,
Speaker 2: with the exception of Skylab the Chinese the space station
Speaker 2: is derived from Salute. All the salutes obviously ends and
Speaker 2: mirror and this Vezda module on the ISS. The core,
Speaker 2: which is the core control module for the International Space
Speaker 2: Station also derived from SCOT from Salute. On the computing side,
Speaker 2: Big Year this is the year that Intel ships the
Speaker 2: four thousand and four, the first CPU. It's an eighteen
Speaker 2: pin DIP twenty three hundred transistors on board. It's a
Speaker 2: four bit processor at one hundred and fifty killoer hurtz.
Speaker 2: It'll go on to be in a bunch of calculators,
Speaker 2: and of course they'll go on to go onto the
Speaker 2: eight thousand series and everything you're using right now. Yeah.
Speaker 2: The floppy disc is first developed at IBM by a
Speaker 2: guy named Alan Shugart. Although limittedly he led the project.
Speaker 2: He recognized that name if you remember the Shoeguart drive.
Speaker 2: That original floppy disk is an eight inch format. It's
Speaker 2: called the IBM twenty three FD and it is read
Speaker 2: only oh eighty K of data. There's a separate hardware
Speaker 2: to actually write on the disc. And these were meant
Speaker 2: for updates to the System three seventy, So you would
Speaker 2: get a twenty three FD as part of your System
Speaker 2: three seventy and do updates with eight inch discs. There'll
Speaker 2: be later versions that are rewrite.
Speaker 1: I remember looking through the Radio Shack catalog when I
Speaker 1: was a kid, and there were computers that took the
Speaker 1: eight inch floppies of the model too, took the eight
Speaker 1: inge drive, yeah, and I thought that was like the stuff,
Speaker 1: you know, it's pretty cool. I just so wanted a
Speaker 1: computer when I was a kid, for sure. It wasn't
Speaker 1: until I was almost in high school that my father
Speaker 1: bought one.
Speaker 2: But they only got better with time.
Speaker 1: Here's another story, another story to interrupt. When I was eleven,
Speaker 1: nineteen seventy eight, there was a huge blizzard in New England,
Speaker 1: Blizzard of seventy eight. We got like four or five
Speaker 1: feet of snow and so there wasn't any school that day,
Speaker 1: and my friends and my brother and I we decided
Speaker 1: to build not just a snowman, but we built a
Speaker 1: space station and called it Skylab.
Speaker 2: Nice.
Speaker 1: Isn't that cool? Yeah? I was like, why Skylab? It
Speaker 1: had little shoots and stuff for snowballs running down it
Speaker 1: and it was one of the happiest days of my
Speaker 1: life in school, probably because there was no.
Speaker 2: School, but snow days are always good days without a day. Yeah,
Speaker 2: last things In nineteen seventy one, the Arpanet stuff so
Speaker 2: went live the year before and now we're starting to
Speaker 2: build products on it. So Ray Tomlinson sends the very
Speaker 2: first email. This guy's from MIT, but he was working
Speaker 2: for BBN by them, which is both Barnic and Newman.
Speaker 2: Most people have a dot heard of BBM, but they
Speaker 2: were essential to the creation of the Internet. That very
Speaker 2: first email has a lot of the stuff you already
Speaker 2: recognize today. Uses the app notation for name and domain.
Speaker 2: It has to send her a subject, date, a body.
Speaker 2: There's an argument Tomlinson doesn't have the email anymore, so
Speaker 2: they asked him, well, what was in it? He says,
Speaker 2: I don't know test one, two three or the Cordy
Speaker 2: row like, I don't know something like that. It was
Speaker 2: a test email. Yeah, but over on the Berkeley side,
Speaker 2: so that's east coast. On the West coast side, Mary
Speaker 2: Turnoff of Berkeley, who works for the Office Emergency Preparedness,
Speaker 2: builds a system called the Emergency Management Information System and
Speaker 2: Reference index are IMASARI, which is real time Chat wow,
Speaker 2: and he has ten offices communicating in real time via
Speaker 2: nineteen seventy one.
Speaker 1: The first time I said, I saw that at a
Speaker 1: friend's house who is connected over a modem to somebody.
Speaker 1: I was just amazed. It's stunning, right, So it's stunning,
Speaker 1: like that's somebody typing in real time. Yeah, on the
Speaker 1: other side of the world, potentially.
Speaker 3: Yeah, I have a question, Richard.
Speaker 2: Yes, hey, Egil, speak up.
Speaker 3: Gil yeah, sorry, I'm really holding my breath yet. But no, like,
Speaker 3: did they actually have the at sign back when the
Speaker 3: first email was sent out?
Speaker 2: Apparently? Yeah, they said the acts of what was included
Speaker 2: in the original email structure. So you know, I mean
Speaker 2: it's nineteen seventy one, so ASKI exists. It's just a
Speaker 2: question of this is mostly mainframe computers at this point,
Speaker 2: where there using ASCI, where they using embedict, there's a
Speaker 2: lot of IBM. Then, Yeah, so it could have been.
Speaker 3: But it probably wasn't printed on the keyboard, I guess.
Speaker 2: Yeah. Yeah, it's hard to get your head around what
Speaker 2: the hardware looked like back then. But then this was
Speaker 2: mostly universities and military labs on arpedet. Right, it's not
Speaker 2: inner yet, so they're all largely mainframe machines, PDPs and ibms.
Speaker 2: Very cool.
Speaker 1: Yeah, so that's your list, Richard, that's my list. Well
Speaker 1: in that case, it's time for better no of framework.
Speaker 2: Awesome rold of music. Man, what do you happen?
Speaker 1: So, as you know, it's my moo to go looking
Speaker 1: for things that are training on GitHub and I found
Speaker 1: this Hardened Windows Security the new threat to malware. Hardened
Speaker 1: Windows Safely securely only with official Microsoft methods, So this
Speaker 1: is essentially training and it's a repository that the features
Speaker 1: have already been implemented by Microsoft and Windows to fine
Speaker 1: tune it towards the highest security and locked down state
Speaker 1: without relying on any third party component or dependency, using
Speaker 1: well documented, supported, recommended, and official methods. So I think
Speaker 1: this is really cool because one of the big problems
Speaker 1: in security, as you guys know, is the chain. You know,
Speaker 1: the supply chain, what dependency or are you using and
Speaker 1: what dependencies are they relying on, And if you draw
Speaker 1: graphs sometimes you can see the spokes go out in
Speaker 1: millions of directions and it's impossible to wrap your mind around.
Speaker 1: So I really like this for the fact that you know,
Speaker 1: you're not relying on some GitHub repo where somebody could
Speaker 1: come and do a pull request that isn't looked at
Speaker 1: carefully and it's got some malware in it, and that's
Speaker 1: that's a reality today. So yeah, I'm very much in
Speaker 1: favor of doing what's on the box. You know, what
Speaker 1: can I do that's right here.
Speaker 2: So and to be clear, this is not an app
Speaker 2: in GitHub that you compile or anything. This is just
Speaker 2: a list of information and some scripts Power Show to guidance. Yeah,
Speaker 2: just guidance to implement features that already exist in Windows
Speaker 2: or perhaps have Microsoft based tools in some cases, to
Speaker 2: just turn up the security level on your machine. You know,
Speaker 2: Microsoft tends to default to everything works, it's easy to use, right,
Speaker 2: and then highly secure.
Speaker 1: As we say on our show, security is the enemy
Speaker 1: of convenience and vice versa. And so if it's very convenient,
Speaker 1: the fact of the matter is, it's probably less secure
Speaker 1: than you wanted to. But there are ways to to,
Speaker 1: you know, get get as close as you can to
Speaker 1: convenient and be secure at the same time. And I
Speaker 1: think that's you know, it's a guidance like this that
Speaker 1: helps us with it. But you know, knowing what we know, Richard,
Speaker 1: when you come across people in your daily life who
Speaker 1: are asking you, you know, I got this text message
Speaker 1: or I got this email, what is that? And you
Speaker 1: know your answer is ignoring it and you're rolling your eyes.
Speaker 1: It's like most people out there are so vulnerable and
Speaker 1: susceptible to phishing attacks and yeah, dude, you don't know
Speaker 1: where to start.
Speaker 2: It's worse than that. A friend of mine shows me
Speaker 2: as one of my neighbors shows me the out box
Speaker 2: on the email on his iPhone and it's full of
Speaker 2: spam sent through his account, and I'm like, dude, you
Speaker 2: need to change a password. He's like, oh, no, I
Speaker 2: can't do that. Yeah. Like, why I'm not changing my password.
Speaker 2: It's not hurting me. I'm like, you're sending spam mail.
Speaker 3: Your reputation take a hits.
Speaker 2: Yeah, Nope, not changing the password. Step too far, not
Speaker 2: a thing. Not going to do that.
Speaker 1: Yeah, let me introduce you to a password manager, my friend.
Speaker 2: Please.
Speaker 1: Well, anyway, that's what I got. Richard, who's talking.
Speaker 2: To us, grabbed a comment off of the show eighteen
Speaker 2: sixty eight when we did with one Eagle Hints and
Speaker 2: maybe you've heard of him talking a little bit about
Speaker 2: the updates around b unit. This is from twenty twenty three,
Speaker 2: and our friend Joe Finney had a comment on the
Speaker 2: show which I thought was very appropriate. He said, I
Speaker 2: really appreciated how Eagle made the distinction between different kinds
Speaker 2: of open source projects. I think in addition to having
Speaker 2: a licensed file in the REPO, maybe projects should have
Speaker 2: a goals file which states what the owners of the
Speaker 2: project would like to see it become. There's a little
Speaker 2: one off experiment, but a complete end user application looking
Speaker 2: to be improved but not really built upon. Is the
Speaker 2: project more of a framework supported by a business to
Speaker 2: help with integrations and so on? Like, what's the intent?
Speaker 2: I love it that would help consumers of the project
Speaker 2: know what to expect when opening issues. Prs are looking
Speaker 2: for support. As always, Thanks for the great show. It's
Speaker 2: all refreshing to hear smart people discussing hard problems.
Speaker 1: Yep, even if the answer is how should we know?
Speaker 2: Well? And we just had Joe on the show too, right,
Speaker 2: it was the previous week, so it's only coincidental that
Speaker 2: I happened to find a comment from them from eagles
Speaker 2: last show, which I thought was very relevant. So Joe,
Speaker 2: thank you so much for your comment in a copy
Speaker 2: of music. Co Buy is on its way to you,
Speaker 2: and ifew'd like a copy of music, go buy right
Speaker 2: a comment on the website at don arogs dot com
Speaker 2: or on the facebooks. We could publish every show there
Speaker 2: and if you come there and everything on the show,
Speaker 2: we'll send you a copy of music to Coba.
Speaker 1: Music code by still going Strong and twenty two tracks.
Speaker 1: You can go to music too coode by dot net
Speaker 1: to purchase the collection in MP three wave or FLACK format.
Speaker 1: Go for it Flack. Okay, well, let's bring back Egil Hanson.
Speaker 1: Of course, he is the author and inventor of b
Speaker 1: unit for testing Blazer apps and components. So let me
Speaker 1: read his official bio.
Speaker 2: Egil is a.
Speaker 1: Dane chilling in Iceland. He's a developer at Delegate and
Speaker 1: a Microsoft MVP. He chats globally at conferences about nifty
Speaker 1: developer stuff and is all about that clean maintainable code.
Speaker 1: I love that song. I'm all about that clean maintainable code.
Speaker 1: That clean maintainable code. He's the creator behind b unit,
Speaker 1: as I said, for Blazer tests and angle sharp diffing
Speaker 1: think spot the HTML difference in c sharp. Though he's
Speaker 1: danced too many tech tunes, Eagle's current jam is everything
Speaker 1: dot net and cloud. Check out his repos at GitHub
Speaker 1: dot com slash Egle. Yes, this bio was written by
Speaker 1: chat GBT.
Speaker 3: And it was written what was it three years ago?
Speaker 3: Last time I visited you too?
Speaker 2: So yeah? Yeah? Nice? Uh?
Speaker 3: Still still more today? Yeah? Well, in which you mentioned
Speaker 3: b unit, I have to give a shout out to
Speaker 3: my co maintainer Steve and Giselle who's really pulling a
Speaker 3: lot of the weight around that. These days, we are
Speaker 3: working heavily on a V two of that co mollis
Speaker 3: just simplified a PI is you remove some of the
Speaker 3: craft all of that, and especially removing the support for
Speaker 3: the older target frameworks that we have. We have we're
Speaker 3: still support back to free one dot net core days,
Speaker 3: so it will be nice to to clean that out
Speaker 3: a bit. But so try not to do braking changes.
Speaker 3: So we would have to do a V two to
Speaker 3: actually do that. So so that that will happen hopefully
Speaker 3: the end of this year.
Speaker 2: Very good. Nice, we'll need to do another show. Then
Speaker 2: we talked about the new version.
Speaker 3: Absolutely, yeah, absolutely, that would be good to do.
Speaker 1: So what are you thinking about these days?
Speaker 2: So?
Speaker 3: I well, I, as my bio probably indicates, I used
Speaker 3: to be sort of the B unit guy and and
Speaker 3: there are a lot also conference talks on that, and
Speaker 3: I branched out a bit, so now I'm talking more
Speaker 3: about testing in general and have been double clicking a
Speaker 3: lot on what it means to write valuable tests. So
Speaker 3: so so so that that that's something you know that
Speaker 3: I'm really passionate about making sure that.
Speaker 1: That indicates that there are mostly not valuable tests out there.
Speaker 1: Well exactly, so implies.
Speaker 3: Well, no, not necessarily, not necessarily, But I think I've
Speaker 3: seen and I've certainly been guilty about myself at certain
Speaker 3: cyy st tendency too to not think, not not be
Speaker 3: explicit about what the what kind of test you write.
Speaker 3: So so some some types of tests have different benefits
Speaker 3: from others, and there's no silver bullet, so so be
Speaker 3: you know, be open to new ways of writing tests
Speaker 3: or write new styles of tests. So, I think the
Speaker 3: classic thing you really want from the test we is
Speaker 3: you bought the confidence to be able to say, well,
Speaker 3: all my tests passed, so I haven't made a mistake,
Speaker 3: and we can go straight to production or at least
Speaker 3: through a c c D pipeline where the quality gauge
Speaker 3: is the test among other things, and if all are green,
Speaker 3: well then you know it's it's good. And and for me,
Speaker 3: it's it's about having tests that really gives you the
Speaker 3: I think that's that's four pillars that I think that
Speaker 3: we're quite elegantly described in a book called I Think
Speaker 3: Unit Testing Principal Patterns and Practices by Vladimir Kolikov, which
Speaker 3: I often reference is his way of testing he describes
Speaker 3: in that book is very much aligned with how I
Speaker 3: do it. But he has four pillars sort of that
Speaker 3: indicates if you have a valuable test suite, and it's
Speaker 3: if you have good protection against regression, if you have
Speaker 3: resistance to refactoring, if you have fast feedback, and your
Speaker 3: tests are maintainable. So this is the top exactly. Well,
Speaker 3: so if we take the three first ones, right, protection
Speaker 3: against regressions, you get a lot of that if you
Speaker 3: write more into interests, because regressions is when something breaks
Speaker 3: that you didn't intend to break, or when you make
Speaker 3: a change. Well yeah, well so unintentional change is probably
Speaker 3: what I would call it. Right, And if you do
Speaker 3: into interesting, you're touching on your nukelet package. You're touching
Speaker 3: on all your external dependencies as well as your business logic. Right,
Speaker 3: so if you have good into Interests, you can also
Speaker 3: just upgrade to the data versions of all your external
Speaker 3: packages that you depend on on use and if your
Speaker 3: tests still go through, well you have probably a good way,
Speaker 3: Like it's probably safe to deploy, right, It's probably okay
Speaker 3: or great. But the downside is so the third third
Speaker 3: pillar was fast feedback and obviously, and to insists they
Speaker 3: runt quite a bit slower maintenance. Why is they also
Speaker 3: somewhat harder to maintain because there's usually way more things
Speaker 3: going on, so that does no you know, depending on
Speaker 3: the kind of application you're writing, you can choose to
Speaker 3: either go to integration testing or into interesting or have
Speaker 3: a mix of all of that, and that is usually
Speaker 3: my default is to start start with integration testing. And
Speaker 3: then if I find I have a lot of business
Speaker 3: logic letters annoying hard to test through the public surface
Speaker 3: of my way, if it's API I'm building, or product
Speaker 3: product on app or something like that, well then you know,
Speaker 3: you peel away the outer layers of your application and
Speaker 3: isolate your components are your units on the test, and
Speaker 3: test them in isolation, so you get both fast feedback.
Speaker 3: But there's there's no super bullet here.
Speaker 1: I can think of a few situations in which refactoring
Speaker 1: can throw tests off. Say you have a method that
Speaker 1: takes I don't know, three parameters or something like that,
Speaker 1: and so therefore it's up to the calling code to
Speaker 1: have those parameters from wherever they come from, whether it's
Speaker 1: a user or something. And then instead of that you
Speaker 1: decide to you know, make some configuration and the configuration
Speaker 1: has those name value pairs in it now and they're
Speaker 1: not passed in. So you're like, okay, I'll just you know,
Speaker 1: remove these parameters from this method. We're going to assume
Speaker 1: that these two parameters are coming from configuration and blah
Speaker 1: blah blah. So there that'll break a test because oh well,
Speaker 1: I'm calling this still with my parameters, and now I
Speaker 1: have to decide whether I should get those values out
Speaker 1: of the configuration before I pass it in or do
Speaker 1: you know that kind of thing.
Speaker 3: Well, so there's a whole bunch of patterns that you
Speaker 3: can lean into that will give you resistance to refacting,
Speaker 3: which was the second pillar, and really resistance to refacturing
Speaker 3: something that is valiable to aim for, independent of whether
Speaker 3: you're doing into interesting or union interesting. So I think
Speaker 3: the first thing is in general, to keep implementation details
Speaker 3: out of your test if you can. And that's sort
Speaker 3: of a high level. So what does that mean, Well,
Speaker 3: implementation detail is well, actually, okay, that's that's actually something
Speaker 3: I sometimes do when I do this. I do this
Speaker 3: presentation around this, so I ask what are implementation details?
Speaker 3: So an example, if you're building I don't know for
Speaker 3: a consumer phasing applications, so not not building a library,
Speaker 3: but you're building something that users will use. Right, if
Speaker 3: you have a database, would you con see that better
Speaker 3: implementation detail or would you say that that is you
Speaker 3: know something that I think the opposite of the implementation
Speaker 3: details is something that is externally observable. It's something that
Speaker 3: you know changes and that you can then have it's
Speaker 3: okay to have in your tests. So would a database
Speaker 3: be an implementation detail in your mind?
Speaker 1: The database itself, the structure of the database.
Speaker 3: Yeah, yeah, yeah. Could you have something of the database,
Speaker 3: could you have access, could you use could you have
Speaker 3: entity framework in your test, for example, to put some
Speaker 3: data into the database before you run the test, or
Speaker 3: could you acquiring the database and see did my changes
Speaker 3: act to get into the database?
Speaker 2: That smells bad to me?
Speaker 3: Yeah, well you would be right. So implementation details of
Speaker 3: things like that like databases and impliptation details in theory
Speaker 3: in your test or your test shouldn't care about what
Speaker 3: database you're using, because your test should focus on business
Speaker 3: value what you're trying to test.
Speaker 1: You're introducing more complexity.
Speaker 3: Yeah, but when another example could be, well, you have
Speaker 3: an app and it sends out emails whenever users do something. Well,
Speaker 3: you could actually take that, you could take a dependency
Speaker 3: on the email setting functionality in your test because it's
Speaker 3: externally observable. It's part of the external contract that you
Speaker 3: have with the users. So that's a whole host of
Speaker 3: things like this where you have to ask yourselves, is
Speaker 3: it actually something that viewed from the outside when they're
Speaker 3: looking at my application or looking at if you're building
Speaker 3: a component live or class library, is it something that
Speaker 3: is external to the library. And if it's. If it is,
Speaker 3: then it's typically okay because if you actually go and
Speaker 3: change the myth that you talked about before, change the
Speaker 3: parameters you're passed them in a different way, well, you
Speaker 3: actually want your test to break right because you have
Speaker 3: changed the public observable behavior of the whatever you were building.
Speaker 3: But if it's if it's just an internal thing, maybe
Speaker 3: you took a method or method and split it out,
Speaker 3: refractored into an internal class, or you took parts of
Speaker 3: a class that got too big and refactored it into
Speaker 3: a secondary class. Well, in that case, I wouldn't necessarily
Speaker 3: create a testsly for that refactor out class. I would
Speaker 3: just test it again through the public service. I have
Speaker 3: of whatever I'm creating, so so so thinking hard about
Speaker 3: how to keep implementation details out of test. But it's
Speaker 3: also the hardest problem, honestly, incurading good test suite. And
Speaker 3: usually when you have to, like if you have whatever
Speaker 3: you're testing the class, for example, if it takes a
Speaker 3: bunch of parameter as input and all the and you
Speaker 3: have a whole set of tests, but I actually need
Speaker 3: to do the same thing. Do that do that system
Speaker 3: montal test up and passing parameters to it. Well, you
Speaker 3: can refacture that into a small help me method that
Speaker 3: syst next to the test, and that instantiates the suster
Speaker 3: butter test for you. So when you actually have to
Speaker 3: change things, you have one place to go. You don't
Speaker 3: have to break all the tests.
Speaker 2: Right.
Speaker 3: Or at least when you do break them. I think.
Speaker 3: Another thing I have strong feelings about is if you
Speaker 3: are using generic marcking framework like EMQ or in substitute
Speaker 3: in your test. So maybe you decided you have some
Speaker 3: business logic and it's maybe talking to an API or
Speaker 3: back end, so you don't want to have that part
Speaker 3: of your test. You don't want to do intern testing,
Speaker 3: and in this scenario. So you have a surface an
Speaker 3: interface that you put that external communication behind. But if
Speaker 3: you then use MOQ or in substitute or other marking libraries, well,
Speaker 3: the way that you're the code that you are writing
Speaker 3: test for is interacting with that external dependency or out
Speaker 3: of process dependency, which is typically what you would use
Speaker 3: that for. That's an implementation detail most often than not,
Speaker 3: especially if it's a database or something that's internal application.
Speaker 3: If it's sending an email to an email server, that's
Speaker 3: a different story. But in the case where you have
Speaker 3: a database or an event top or some other internal
Speaker 3: out of process thing you have, if you use a
Speaker 3: marking framework, you're likely going to in every test to
Speaker 3: have that set up there. You say, well, when this
Speaker 3: method is called on my interface, I want you to
Speaker 3: respond with this, and I want you to do X,
Speaker 3: Y and z, And you might also want to asserte
Speaker 3: in your test on the MUG that it received a
Speaker 3: certain amount of course with specific input and output. All
Speaker 3: of that is implementation details. It's implementation details of how
Speaker 3: your system under test is using them using the dependency
Speaker 3: it has. So if you at some point change your
Speaker 3: logic so that you don't save to the database. Every
Speaker 3: time it gets a new thing in, it keeps it
Speaker 3: around the memory a little bit, and then it's saved
Speaker 3: maybe to you know, save one. Don't Well, if all
Speaker 3: your test assume that it's going to save one time
Speaker 3: every time it does a thing, now all your tests
Speaker 3: are broken, and they shouldn't be breaking because the functionality
Speaker 3: is still right, still right. The implementation details have changed,
Speaker 3: but not the functionality itself.
Speaker 1: So let's talk about interfaces, shall we. As saying you
Speaker 1: and me, I'm saying, yeah, you know that's uh. An
Speaker 1: abstraction layer is critical when you're doing marking.
Speaker 3: Well, yeah, right, Well you.
Speaker 1: Just want to swap one service in for another.
Speaker 3: So yes, and though well, in general design wise, I
Speaker 3: want to give a shout out to Mark Sieman as well.
Speaker 3: He has an actual book book called Code that Fits
Speaker 3: in New Head I believe actually did an interview with
Speaker 3: him on the podcast about that book and he in
Speaker 3: there for people who want to double click on this.
Speaker 3: He talks a us about, you know, keeping the abstractions
Speaker 3: or interfaces at the edge of the system, and especially
Speaker 3: at the edge where you maybe have some out of
Speaker 3: process communication going on, where you have something that doesn't
Speaker 3: that isn't easily h spun up during a test test
Speaker 3: unit test for example. So in general I am fine
Speaker 3: with introducing interfaces at the itch or if you know,
Speaker 3: things starts hurting. I don't introduce interfaces into my code
Speaker 3: just so I can not doing testing. Okay, if unless
Speaker 3: that is the pain point, I actually prefer the testing
Speaker 3: style I believe it's actually called, I think the Chicago
Speaker 3: school of testing or our classic school of testing, where
Speaker 3: you test from the outside in and you if you
Speaker 3: touch one to five ors in classes doesn't really matter.
Speaker 3: I don't want to test each class in isolation and
Speaker 3: put interfaces around all like every single class has an
Speaker 3: inservace in front of it so I can mark out
Speaker 3: it's if it's been used as a dependency somewhere else.
Speaker 3: I don't really see a lot of value in that.
Speaker 3: And again it also leads to just a lot of
Speaker 3: maintenance and maintainability of your test just goes down.
Speaker 1: Mark Semen is one of our favorite and favorite smart people.
Speaker 1: He is a great Dane, isn't he he is?
Speaker 3: He's frankly, he's he's quite a bit better at explaining
Speaker 3: some of these things that I feel I am. I
Speaker 3: really he's an expliration for sure.
Speaker 1: So I have a little story here. I was working
Speaker 1: for a company that had some data that they were
Speaker 1: pulling from Oh let's just say it's stock data, and
Speaker 1: it was coming from a real time place, and they
Speaker 1: wanted to have this real time update of these tickers
Speaker 1: and stuff, right okay, But their secret sauce was secret,
Speaker 1: and I didn't want to be I didn't want to
Speaker 1: interface with it because that makes me liable in case
Speaker 1: of a data breach or something like that. So I said,
Speaker 1: look right up front, We're going to make an interface
Speaker 1: at this edge, and I'm going to write a little
Speaker 1: number generator with a timer or whatever to send me
Speaker 1: my data over and I'll pass that over to you
Speaker 1: when I'm done, and then you can wire up your
Speaker 1: back end stuff. I don't want anything to do with it.
Speaker 1: I'm a UI guy at this point, right. So that
Speaker 1: was I wasn't using any mocking framework or anything. We
Speaker 1: just created an interface and it was their interface, and
Speaker 1: I said, all right, here's the data that I'm going
Speaker 1: to give you, here's the method that i'm going to
Speaker 1: call when I have new data, and then and Bob's
Speaker 1: your uncle. So in that case, it was the it
Speaker 1: was the business agreement and that dictated that we use
Speaker 1: that method.
Speaker 3: Well, I think so. I think that's a completely fair
Speaker 3: use of interfaces. So, if you have something that is
Speaker 3: external to your application, put an interface in front of that,
Speaker 3: or in domator and design we call that an inter
Speaker 3: corruption layer. You create a facade but sits in front
Speaker 3: of some external thing that you have to talk to
Speaker 3: or that talks to you. And and that is so
Speaker 3: that if they change whatever they're doing, it doesn't affect
Speaker 3: your cover. You have a facade.
Speaker 1: So that and more importantly, I don't know the implementation
Speaker 1: details on the back end, and then that's a good thing.
Speaker 3: They're not important to you exactly. And I'm so in
Speaker 3: general like those kinds of thing, and even when I'm
Speaker 3: using mocking framework, that's fine. My go to actually is
Speaker 3: if I have something out of process that is also
Speaker 3: externally observable, I would just handcode, you know, a custom
Speaker 3: mock or fake for that interface, because it's gonna instead
Speaker 3: of having repeated in every single test the setup code
Speaker 3: for my whatever what needs to do, I just have
Speaker 3: a generic fake implementation of the interface if it's repository
Speaker 3: or sending an email or something, and it will be
Speaker 3: using my domain language instead of the generic Marcking set
Speaker 3: up language, which is well, you learn to read it,
Speaker 3: but it's it's not the same language that the rest
Speaker 3: of your program is. It's the custom API, right, So
Speaker 3: I find that that is valuable and if you can,
Speaker 3: probably you can more often can you can reuse those
Speaker 3: handwritten marks of face throughout the different tests because you
Speaker 3: tend to make them just like they just immurate the
Speaker 3: behavior of whatever you're interfacing with. So the fake of
Speaker 3: the mark itself, the handwritten one, will also be a
Speaker 3: documentation for how you expect the the third party to behave.
Speaker 3: So if that changes, you go and update the fake,
Speaker 3: and then all the tests don't change because they still
Speaker 3: have the same surface and likely on this there's actually
Speaker 3: new behavior. Well the tests actually have to change. The
Speaker 3: test will still keep running, so you have a secret
Speaker 3: place you have to update instead of having you know,
Speaker 3: you change them something in one interface, and then all
Speaker 3: the tests break because all the bogs are now wrong
Speaker 3: and you need to do update the configurations all the
Speaker 3: tests that use the same interface or lock that interface out.
Speaker 3: So yeah, it's about spending a little bit of extra
Speaker 3: effort initially to create the fake versus just using the
Speaker 3: generic marcking library, and it will save a lot of
Speaker 3: time in the long run. I think in my experience.
Speaker 1: That's very cool and it feels like a good place
Speaker 1: to take breaks. So we'll be right back after these
Speaker 1: very important messages stick around. Did you know you can
Speaker 1: lift and shift your dot net framework apps to virtual
Speaker 1: machines in the cloud. Use the elastic bean stock service
Speaker 1: to easily migrate to Amazon EC too with little or
Speaker 1: no changes. Find out more at aws dot Amazon dot
Speaker 1: com slash elastic beanstock.
Speaker 2: And we're back. It's dot net rocks amateur Capbell. Let's
Speaker 2: call Franklin Yo. Yeah, I can do our friend Eagle
Speaker 2: Henson a bit about you know, making really valuable tests too.
Speaker 2: Recently we did a show with w O'Brien talking about
Speaker 2: the MCP for playwright Wonderful, and it made me start
Speaker 2: thinking about how we make more resilient tests by not
Speaker 2: writing the tests at all, but by writing prompts to
Speaker 2: generate tests so that we would be able to regenerate
Speaker 2: tests pretty quickly with those kinds of tools, Like how
Speaker 2: important is it to handwrite this test code versus using
Speaker 2: these generative tools for writing that kind of code. You
Speaker 2: knew we were going to get to add sooner or later.
Speaker 3: Yeah, well we have to check that box. I think
Speaker 3: it's an excellent question, and I am using I'm playing
Speaker 3: around both of Claude and with all the OMII tools
Speaker 3: from GitHub as well. I think, you know, back to
Speaker 3: my original point, is a good test suite is something
Speaker 3: gives you confidence. I have tried to was it a
Speaker 3: vibe code or just have an agent code, you know,
Speaker 3: a library for me, something I needed for production app,
Speaker 3: something you know, a bit more complex, not just a
Speaker 3: simple thing. And it was a general a good experience,
Speaker 3: like we would go through all the things, and I
Speaker 3: told it to go in a very strict TDD fashion.
Speaker 3: So we brought brought down to this was carawed. I said,
Speaker 3: you know, we're going to do GDD and just break
Speaker 3: down and take the most simple thing we can build
Speaker 3: first and write a test for that, then write code
Speaker 3: and some back and forth. But at the end of
Speaker 3: you know, a long day of experimenting with that, that
Speaker 3: was quote and all the code passed or all the
Speaker 3: tests passed, and the production code was there. I wasn't
Speaker 3: sure if but honestly I didn't trust it because for me.
Speaker 3: The key part when I'm actually writing a test or
Speaker 3: writing production code is I am I'm thinking about like
Speaker 3: all the turns that I don't take during writing test,
Speaker 3: like thinking about, well can I do this? No, that
Speaker 3: doesn't work because X, Y and C. And then I
Speaker 3: discover something else I need to think about as well
Speaker 3: when I sort of problem solve go through it. I
Speaker 3: haven't found a way with AI agency yet to get
Speaker 3: that same experience where I know I've been through all
Speaker 3: the educases and I've thought about that because I know,
Speaker 3: go for one.
Speaker 2: But you only see those educases by writing the primary
Speaker 2: case and bumping into them. So it's the thought exercise.
Speaker 2: It is, Yeah, that happens right right, the code that
Speaker 2: actually helps you find those edges.
Speaker 3: It helps. So one thing I have done is I
Speaker 3: have either tried to write the production code, the code
Speaker 3: that needs to some testing at some point, write that
Speaker 3: by hand without tests first, and then tell, you know,
Speaker 3: a AI agent of choice to go look at the
Speaker 3: changes I have here and write tests that test these things. Right,
Speaker 3: and if I have existing tests already, you know, look
Speaker 3: at the existing tests, see how they're structured. Maybe I
Speaker 3: write one or two tests myself because I want it
Speaker 3: to be done in a specific way, and then it
Speaker 3: can typically iterate over it and figure out well, these
Speaker 3: are all the it's cases, these are all the branching
Speaker 3: got things we need to test for, and it will
Speaker 3: bid out a whole bunch of tests. But I've also
Speaker 3: seen when I looked at some of the code that
Speaker 3: has been generated sometimes that will be a test where
Speaker 3: that is a source just doesn't make sense. So I
Speaker 3: don't think it's a silver bullet. You definitely need to
Speaker 3: do a ferral review like you would with if you
Speaker 3: have an open source and you get a pro request
Speaker 3: in from somebody you don't know, you really have to
Speaker 3: read food very carefully, and at that point if it's
Speaker 3: something very deeply technical. I my experience is that the
Speaker 3: amountlets time it really takes to do a very ferl
Speaker 3: review of the code you have received from somewhere like
Speaker 3: it's almost as you could have just written it yourself.
Speaker 3: Like at that point, if you.
Speaker 2: The energy to do that, reviews same energy as to
Speaker 2: write it.
Speaker 3: So what I do like with alarms is that they
Speaker 3: are really really good at reviewing things though, so you
Speaker 3: so using them using them with githob assigning copilots as
Speaker 3: a reviewer, they usually always find something. Sometimes it's just nitpicking,
Speaker 3: like you spell this word wrong, or but sometimes that
Speaker 3: is actually think so elerms. I think much more valuable,
Speaker 3: at least in my workflows right now, in reviewing what
Speaker 3: I've done and giving me feedback or having that back
Speaker 3: and forth. Whether we are just iterating on ideas, sparring
Speaker 3: and what didn't I think about here? And there would
Speaker 3: be something? So that add lots.
Speaker 1: So we're getting into using models to generate tests, and
Speaker 1: then using models another model perhaps to value and validate
Speaker 1: it and review it.
Speaker 2: And software arguing with software.
Speaker 1: Maybe maybe this is our future, you know, and we
Speaker 1: are layers of models.
Speaker 2: But it speaks to and I know you're working on
Speaker 2: a B in a two point Oh, it's like, should
Speaker 2: there be an MCP for B unit just so that
Speaker 2: those features are easily exposed to a prompting system.
Speaker 3: So I think it could be. I think our MCP.
Speaker 3: So what would be, you know, quite extensive documentation with
Speaker 3: examples so that say go and look at the documentation
Speaker 3: and figure out how to make this test work. I
Speaker 3: think that that is I think a difference with playwright
Speaker 3: and the MGP. So what they have is because you're
Speaker 3: actually running a browser that has words of API. So
Speaker 3: so it's it's a slightly different scenario.
Speaker 2: I think one thing necessary abstraction, Yes.
Speaker 3: And again. So now you can also say, well, if
Speaker 3: you have a generally a whole bunch of test cases
Speaker 3: for whatever you're building, well those are either another ELM
Speaker 3: or yourself that has to maintain those going forward. So
Speaker 3: there is a point to having, you know, slipping that
Speaker 3: down or at least looking critically at them and saying this,
Speaker 3: this is actually a valuable test. Does that actually test
Speaker 3: something that other tasts aren't testing already? Right? I did try,
Speaker 3: which is something I want to experiment more with. Have
Speaker 3: you heard about striker dot net it's a mutation testing
Speaker 3: framework from my yourself, Well, it's it's from different platforms.
Speaker 3: So is so with mutation testing? What it does? It
Speaker 3: takes your test suite and then it says your production code,
Speaker 3: and then find conditionals in your production code, and then
Speaker 3: and it flips flips that conditional at at a very
Speaker 3: basic level, and then it runs all your tests. If
Speaker 3: it all your tests pass with that flip conditional, well
Speaker 3: then you have they call it a mutant that survived
Speaker 3: it's you know, from the x N universe, and and
Speaker 3: it will you said it loose on your code base.
Speaker 3: You need to have everything building and compiling. I'm always
Speaker 3: just passing before you do that. But it will then
Speaker 3: spend ten minutes, fifteen minutes as long as you wanted
Speaker 3: to go, just going through all your production cont finding
Speaker 3: bits to flip. And it will do that, and it
Speaker 3: will run all your tests and if some tests, if
Speaker 3: that's test that doesn't fail, well then it reported back
Speaker 3: to you in a in a in a report you
Speaker 3: get after the run that tells you, well, I flipped
Speaker 3: these conditionals and there were no tests that broke when
Speaker 3: I did that. So I find that to be a
Speaker 3: much better metric for whether or not I have good
Speaker 3: code covers or not, because just going crossing over a
Speaker 3: line during a test doesn't mean you actually, you know,
Speaker 3: I'm sitting here on video doing the you know.
Speaker 2: Podcast That doesn't work.
Speaker 3: So I actually asked Claude to say go down too, Striker,
Speaker 3: because it claimed that it is done, it had done
Speaker 3: all what to do for that library, low level libry building,
Speaker 3: and then run this against it, and then it's spent
Speaker 3: two hours more just running Striker look at the report
Speaker 3: than adding more tests. So that is you know a
Speaker 3: way to go forward and find find the test that
Speaker 3: you haven't written yet.
Speaker 2: Interesting, Yeah, because we're presuming all mutations are bad. You
Speaker 2: know that's this very x men.
Speaker 3: Well no, so yeah, if you go this website striper
Speaker 3: dot net. But if you go and look there, you
Speaker 3: will see there will be mutations where you can see that.
Speaker 3: It's never it's like it's on reasonable code. As soon
Speaker 3: as they flip that bit.
Speaker 2: You shared striker dot net, isn't it striker mutator dot io.
Speaker 3: Maybe they changed the U own.
Speaker 2: Yeah, because it's that that's the site with JavaScript, n C,
Speaker 2: sharp end Scala.
Speaker 3: Yeah, yeah, it's it's uh yeah, you're right, Striker.
Speaker 2: Mutata including the show notes for folks who want it
Speaker 2: helps you find the code that has leaked out of
Speaker 2: your head.
Speaker 3: So it's it's a very It will also report things
Speaker 3: and obviously it can flip a bit and then the
Speaker 3: compiler doesn't it doesn't compile anymore, and that is also
Speaker 3: counted as you know, that's just stetic tybing.
Speaker 2: That's easy to do. I do that all the time, exactly.
Speaker 2: But I love this idea that you it makes changes
Speaker 2: to code. It still pass. But still the question is
Speaker 2: is the code now incorrect?
Speaker 3: Well, the point is it's about checking if your test
Speaker 3: tweet is giving your protection against your questions. Because if
Speaker 3: I can go and flip the bits and no, none
Speaker 3: of my test of breaking, I might it might just
Speaker 3: not be a nothing, but it might also be that
Speaker 3: I've broken the behavior of my application. Absolutely, So you
Speaker 3: want your test weite to capture or to catch those
Speaker 3: things if it's important. So, yeah, Typically when I run
Speaker 3: Striker on my code, that is quite a large list,
Speaker 3: and some of them you just say, well, that's not
Speaker 3: an issue.
Speaker 2: I'm not going to do that. Yeah, Gail, do you
Speaker 2: hate nells as much as I do?
Speaker 1: For testing? Aren't they like the worst? Do you like
Speaker 1: when you create a test, should you automatically should your
Speaker 1: framework automatically check for nolls before I actually add more tasks?
Speaker 3: Well? I think we are. Well, we're talking dot Net.
Speaker 3: We have we have a compiler that will do that
Speaker 3: for us, so I will I.
Speaker 1: Will use If they change it run time and you're
Speaker 1: not doing any null checking, there's a runtime error that
Speaker 1: can occur and often does.
Speaker 3: So I think that's that's the things between what kind
Speaker 3: of things. You're if you're building a component, well at
Speaker 3: a reusable library that you probabish as a NUCAD, you
Speaker 3: would want even if you have noables enabled in your library.
Speaker 3: When you're building it out and you use all the
Speaker 3: right attributes, your in user, which is not in the
Speaker 3: same compile space as you are, can passing. Yeah, they could.
Speaker 3: They can pass in a all because they might have
Speaker 3: turned Dollible off in their compiler.
Speaker 2: Right.
Speaker 3: So on the so, if you're building a library, definitely
Speaker 3: on all your public GAPI surfaces, I add indult checks
Speaker 3: or in general, you know, just use the various arguments
Speaker 3: out of range and all of that checks. Because you
Speaker 3: can't will do that and bid units. You can't trust
Speaker 3: your users to do the right thing, or they might
Speaker 3: just have apology of not using nollible in their code base.
Speaker 3: If I'm building a line of business application or internal
Speaker 3: applications where everything that gets compilers compiled by my compiler,
Speaker 3: how I compuget it. I am much more inclient to
Speaker 3: just trust that. You know, if we've said that this
Speaker 3: object here can not when you pass it into this method,
Speaker 3: well the compiler will tell me if I'm trying to
Speaker 3: pass in an object. I think it's especially the later
Speaker 3: version of c Shop has gotten very good at basically
Speaker 3: understanding how objects flow and capture that.
Speaker 1: Okay, it has, but when we turn nullible on now
Speaker 1: we see a lot of squiggles from the compiler and
Speaker 1: visual studio. Yes, and I think of them sometimes as
Speaker 1: noise because it's everywhere, and I know that could be
Speaker 1: no but it's not because I'm clearly looking at the
Speaker 1: code and so I'm probably not alone in that. A
Speaker 1: lot of developers so that out you know, I hear you.
Speaker 3: I would strongly recommend that to really work well with
Speaker 3: notable enabled, you have to enable it. And then I
Speaker 3: also always enable three warnings as errors, at least in
Speaker 3: my release belts. And then we simply don't like I
Speaker 3: would if you have, for example, if you know you're
Speaker 3: talking to external things like it's not part of your
Speaker 3: internal business logic domain, where sometimes you can have an
Speaker 3: all come in or the library will tell you that
Speaker 3: this may be not even though you know in all
Speaker 3: my use cases it's never going to be all right. Well,
Speaker 3: I just put a guard in at the itches so
Speaker 3: I know that within my code everything is not knowable,
Speaker 3: and it's a bit annoying. Sometimes you have to add
Speaker 3: an additional check just because, right you can.
Speaker 2: But but I do that all the time.
Speaker 1: I'm it's in my DNA to put those centuries in
Speaker 1: place at the edge.
Speaker 3: So but if you force yourself into not not accepting
Speaker 3: any normal warnings squigglies and simply deal with them at
Speaker 3: the ages where you are, then you are much less
Speaker 3: likely to have problems, at least in my experience.
Speaker 1: But that's you know, except now you're going to spend
Speaker 1: an extra hour getting rid of those squiggles.
Speaker 3: I'm sure co Pilot can help you with that.
Speaker 2: I'm sure exactly.
Speaker 1: That's a good use for a Hey, get rid of
Speaker 1: all them spriggs.
Speaker 3: They are actually quite good at figuring something like that out.
Speaker 3: And obviously you have to do a bit of monitoring
Speaker 3: on on things as well afterwards, reviewing the changes.
Speaker 2: Right.
Speaker 3: Actually, speaking of Mark Semen, I wanted to call out
Speaker 3: something else which I find is right quite interesting, is
Speaker 3: naming of tests. So I want so because there's no
Speaker 3: right or wrong here. But he had a good blog
Speaker 3: post a while back, so let me let's me test
Speaker 3: out the scenario on YouTube. So imagine we have I
Speaker 3: don't know, a podcast met Ninja class and and we
Speaker 3: want to write it has a feature where you can
Speaker 3: upload a new podcast and it maybe have to go
Speaker 3: life time in the future, So we want to write
Speaker 3: a unit test for that feature. So just off the
Speaker 3: top of the head, what would you name that test?
Speaker 3: Like the test where we're just uploading a file call
Speaker 3: the surface of the API and say, oh, here's his
Speaker 3: new podcast and has a good life date and you
Speaker 3: know something, you know, some assertions should happen as well,
Speaker 3: what what what name would you give that test?
Speaker 1: Well, if I worked for Microsoft, I'd call it uh
Speaker 1: foundation framework for testing podcast uploading and checking to see
Speaker 1: if it's valid.
Speaker 2: Yes, something like that.
Speaker 3: So something about something with the whatever you using, then
Speaker 3: maybe the action and then some expected outcome assertion. Right, yeah,
Speaker 3: and I so Mark had a really great point. Whenever, well,
Speaker 3: at least for my sake, I guess for Marks as well,
Speaker 3: whenever I read a test, when I come into a
Speaker 3: test I haven't seen before somebody else has written bad,
Speaker 3: I actually usually just skip over the name of the
Speaker 3: test and start reading the code because my experience is
Speaker 3: that you can't you can't fit all the details in
Speaker 3: the name anyway. So we'll just end up reading the test.
Speaker 3: And then the name is more of a mandatory comment
Speaker 3: because methods have to have a name in cl but
Speaker 3: but they can also contend to go stale like the name.
Speaker 3: Like I so many times I've seen a unit test
Speaker 3: where the name said that it included, for example, bessertion
Speaker 3: or expected outcome in the name, but the outcome changed
Speaker 3: because business requirements changed, right, but they forgot to update
Speaker 3: the name of the test. So now you have it.
Speaker 3: You're reading the code when you're looking at a test
Speaker 3: name and they don't match up, and you're going back
Speaker 3: and forth, what is the right thing here?
Speaker 1: So usually they start with If I wasn't being flipped,
Speaker 1: I would say it's start with should.
Speaker 3: Yeah, because that's another good word that explains exactly you know,
Speaker 3: filler words as well, well, that's another pet peeple. So
Speaker 3: I think were my recommendation, and what I learned from
Speaker 3: Mark as well, was to just use the business scenario
Speaker 3: in the description. So in this case, it might be
Speaker 3: something like uploading new podcast with future date future release date,
Speaker 3: So that is the scenario, that scenario. As long as
Speaker 3: you have that feature, it's not going to change. So
Speaker 3: the neighbor of test is not going to change, but
Speaker 3: then you fill out the breadth of the test method anyway.
Speaker 3: So again that makes it so that you have an easier,
Speaker 3: juddiestable test when you get back to it half a
Speaker 3: year later and figuring out why it's broken or it
Speaker 3: just won't to understand what's going on.
Speaker 2: Very good.
Speaker 3: Small details like that are important.
Speaker 2: I think we tend to name the test to the
Speaker 2: class that you're testing and ending it with tests, so
Speaker 2: you can sort out the test if you want to,
Speaker 2: like I kind of want to. I guess I'm always
Speaker 2: thinking from a search perspective, like why am I going
Speaker 2: to find this where? You know? Where is this going
Speaker 2: to live? What is it related to?
Speaker 3: Well, so I think in dot Net, or at least
Speaker 3: in my code, we have all the tests sit in
Speaker 3: the separate project test project, and I tend to have
Speaker 3: I don't tend to have a test class per class
Speaker 3: I have in my production code, but if it's like
Speaker 3: the if it's a public surface a p I, I
Speaker 3: will have a you know class named you know product
Speaker 3: or podcast upload manager tests and that is where all
Speaker 3: the tests belonging to that sits. That's one approach. You
Speaker 3: can also go full b d D and and and
Speaker 3: girking and all of that, and and have just different
Speaker 3: sets of tests, or if you are in a different
Speaker 3: coding environment where you can actually have test code sitting
Speaker 3: right next to the coded tests over classes just mixed
Speaker 3: to it, or whatever terminology they have for their you know,
Speaker 3: test code and production code, that that's also quite valuable.
Speaker 3: It's a bit leaning into the feature foldos concept where
Speaker 3: everything that that does belong together is sitting in the
Speaker 3: same area on disc so you can easily find everything
Speaker 3: that that that does something together. But I don't think
Speaker 3: that's a good option in the dot Ninity system at least.
Speaker 1: So what's next for you? I know you said you're
Speaker 1: working on b UNIT two, yes, and is that taking
Speaker 1: all your time or I mean you're doing a lot
Speaker 1: of conference speaking and that kind of stuff.
Speaker 3: Well, so b unit is taking a little bit of
Speaker 3: my free time. No writing books for me. I I've
Speaker 3: heard from from better folks than me that it's not
Speaker 3: you know, it's it's not a good idea to get
Speaker 3: into that too much. But no, Yeah, I have a
Speaker 3: conference coming up. I think Richard will also be there
Speaker 3: in Stavanna. Hello Stavana in Norway. And and hell was Yeah,
Speaker 3: I'm using the Norwegian pronunciation perhaps uh and but most
Speaker 3: of my days to day job, it's it's it's a
Speaker 3: full time in a little bit. So open source isn't
Speaker 3: getting a lot of attention these days, but we are
Speaker 3: trying to sneak in a few hours every week, me
Speaker 3: and Steven to just jump on a scream or jump
Speaker 3: on a call and get some work done. So so yeah,
Speaker 3: that that is. That is, you know, going back to
Speaker 3: the original comment that you read Richard in the start
Speaker 3: of the podcast from I forget the name, but yeah,
Speaker 3: open sources you know, the work that you do when
Speaker 3: you don't have work and you don't have family time.
Speaker 3: So yeah, so it's it's a big bit on the
Speaker 3: back burner. But I'm waiting for EA agents to come
Speaker 3: and take my open source job for me, and so
Speaker 3: I give it instructions and it will do all the
Speaker 3: right things. It happened, hasn't happened yet, but we might
Speaker 3: be lucky when.
Speaker 1: Yeah, fantastic Ego Hanson, it's been pleasure talking to you
Speaker 1: this hour, and it's always interesting when we sit down
Speaker 1: and talk likewise, and we'll talk to you next time
Speaker 1: on dot net Bronx.
Speaker 2: Dot Net.
Speaker 1: Rocks is brought to you by Franklin's Net and produced
Speaker 1: by Pop Studios, a full service audio, video and post
Speaker 1: production facility located physically in New London, Connecticut, and of
Speaker 1: course in the cloud online at pwop dot com. Visit
Speaker 1: our website at d O T N E t R
Speaker 1: O c k S dot com for RSS feeds, downloads,
Speaker 1: mobile apps, comments, and access to the full archives going
Speaker 1: back to show number one, recorded in September two.
Speaker 2: Thousand and two.
Speaker 1: And make sure you check out our sponsors. They keep
Speaker 1: us in business. Now go write some code. See you
Speaker 1: next time.
Speaker 3: You got JAD Middle Vans the
Speaker 2: Home