>> Hi, welcome to Visual Studio Toolbox,
I'm Robert Green here with Leslie Richardson,
live and together in the studio very
exciting and we're joined by Phil Japikse. How are you?
>> I'm good, I'm herself.
>> Very good.
>> I do agree.
>> Good.
>> It's been a while since we've caught up
so last time I was here,
I wasn't in my current job.
Let me just take a moment to introduce myself or for
the people who haven't seen me or have followed us on the show.
>> Absolutely.
>> Or how doesn't know yourself.
>> Who doesn't know me. Three years ago I took the job as CTO at
Pintas and Mullins were one of
the largest personal injury law firms in
the US so it was a very big change me,
I left consulting that went to
the legal field, which is very weird.
[MUSIC] I'm still Microsoft MVP,
still very active in the speaker community, Prolific author.
My C-Sharp 10 book is doing great,
I am a Scrum Trainer,
although I was five,
I got my Scrum my PST certificate during COVID,
and then I took the job as CTO,
somewhat teaching Scrum anymore.
I think that's it, I run the local user group
and a conference instance,
Daddy so let's catch up with me.
>> Excellent.
>> Leslie, I've done series on
design patterns on Entity Framework
and we're here to kick off
another series on automated software testing,.
>> Correct?
>> Which will be approximately 10 episodes.
We're not quite sure we know what topics we're going to cover.
The want to, keep them nice and short so some of
the topics might take two episodes,
we might decide to stretch them out to three.
We'll figure about 10 or so
covering the gamut of automated software testing.
I guess the first question is,
what's so important about automating software testing?
>> Well, one of the most important thing that we can do as
developers is make sure the code behaves as we expect it to.
I mean, the best thing we can do is have the code behave as
our customers are expected
to but there's sometimes misinterpretations.
We only go based on facts we know, that's what we want to do.
Two are agile development comes in so handy,
because you're constantly demoing it and
showing it negates it adds on what I had in mind.
But the worst thing is you go and build something to
your understanding and you'd go to demo it and you go,
"I wasn't supposed to do that and the customers," like
internal or external customers agreement like what's going on.
We want a way to test it.
We could certainly hit F five and Visual
Studio and debug it and type a bunch of
stuff that takes time
and as developers who don't like doing it, it's boring.
You have QA department to do things but what
a QA department is doing is they're testing the surface area.
They're not getting into the nitty gritty
of how things are working.
>> Which people leave and still have QA departments.
>> Absolutely.
>> That's a lot.
>> A lot of that was that developers
do the testing and then you might have people do final testing?
>> No, because I keep getting email all
the time that my pentose seamless saying, "Hey,
we've got offshore QA,
you want to hire them," in
all of the code calls because they look at
my LinkedIn profile so QA stole thing.
Should it be a thing? Yes, because I think we still need
that holistic 10,000 foot testing view,
but the biggest problem you're going to run into is,
again, it's a time thing.
Let's say you have a password policy that
the password has to be certain number of characters,
has to have a number has to have dollar sign capital letter.
We can write an automated test very,
very quickly to make sure that you can
do a row tasks which will show you when we
get into one of the later episodes,
where it's a data-driven tests.
You have a whole bunch of different
passwords and it should return true
or false if it passes the complexity test or not,
and we can run that
repeatedly for QA to
do that and they can certainly write a script,
but they have to write all those.
Have to login to this system are good to login page,
they have to put in a different password,
and we've got an episode on UI testing,
but we're also going to show you how fragile UI testing can be.
Having QA do this when it's already deployed somewhere,
shouldn't we be testing it before we deploy it?
There's all charts and graphs have if you
catch a bug or a defect in design mode,
it costs this much to fix and all the way to
production and how much it
costs to fix some pre Charlotte numbers are made up.
But I think we can all agree that if
something goes out and production, that's wrong.
To fix it as a significantly more expensive and more work
than if we find it early on in the face.
The automated testing gives
us a rapid feedback loop as a developer,
I'm going to make this change show me what happens.
>> Yeah.
>> That's one of the main things, so it gives you
courage as a developer to make changes.
Because we've all been in
that situation where you're looking at this pile of code.
Maybe it's a 1,000 line method called do it.
You have to make a change in there and
nobody wants to take that story because it codes just scary.
>> Yeah.
>> But if we have well, first of all, if we had tests around,
it wouldn't be 1,000 lines but if we had test around it,
and this is some ways that you can refactor
legacy code and you build
a whole bunch of tests so that when you make changes,
you're going to know if you break something.
We very seldom break things in the direct line of path.
We use you break things, we side-effects.
We've got this big method.
It's not falling single responsibility,
it's doing a whole bunch of different things and then
we were testing our flight path of what we want to do.
To change we want to make but we're not
testing the 27 other things that's method is doing.
I know you're probably thinking, well,
you shouldn't do 28 things in a method and you're spot on,
you should shit, but there's real life.
There's legacy code,
we spend most of our time as janitors,
not as construction, we're
usually cleaning up whether it's
our own code or somebody else's code,
we spend more time cleaning it up and if we had
those tests in place and we needed to make the change,
we'd have the courage to do that because I would
know if I broke something else to test with tell me.
>> But this goes beyond just what we're going to talk about,
goes beyond just writing the tests because you
can write the test, write the code,
run the test, look at the results, modify the code,
re-run the test so you've got the test,
but that's Isn't that a little more manual?
Where's the automated part coming in?
>> Well, the automated part is that frameworks x unit and M spec.
You just fired off from the command line, so dotnet test.
If you're running dotnet six are and you've done
a course harsh dotnet naming is hard.
You can run it from the command line.
You can make it part of your CICD process,
but we're going to have an episode where we talk about tying it
into Azure DevOps pipelines as well as GitHub Actions,
so you can have these things every
time you check into tests get run.
First of all, you'll want to break the build,
that's embarrassing because you could have run
a build on your machine before you check to them, but it happens.
But you also, as a developer,
we don't always say, I have to run
all the unit test before I do a check-in.
Should we probably but we'll talk about why
sometimes you don't because he take
time like Linkedln integration testing,
we have at least one episode on that.
We're actually testing the database
and we'll talk about the semantics around that.
You don't always do that as a developer.
We want to make sure that it gets done somewhere,
and so before you deploy the staging,
right, we want our pipeline and run those tests.
Then we get that again,
that rapid feedback loops at telling us something's wrong.
Your thing that people don't always think about is estimation.
>> I think you've done episodes and
estimation estimating it's hard,
their estimates are not exact estimates. But tests can help you.
Let's say you've got pretty decent code coverage,
and I want to focus on code coverage because it's
actually a red herring typically,
but let's say I've got 80 percent code coverage.
I'd been working in this codebase for six months to build it up,
and somebody comes and says, hey,
we're going to use MySQL to SQL server.
What's the impact? As developers,
we can't sit around and go, I don't know,
let's get a dartboard out,
throw darts, and find a number.
>> Yeah.
>> But what if you just changed
the driver if you're using the f chord,
change it from SQL Server to use MySQL in
your DB context options and then run your tests,
and if half of your tests fail,
you know it took six months to get to where you are,
there's probably three months of work.
Because half of your code isn't broken.
But if 10 tests fail,
well, then you can use your best judgment,
say it's a day or two or whatever.
>> That's awesome.
>> Martin Feathers said the difference
between code and legacy code is test,
and he actually wrote a book Working Effectively With Legacy Code.
It's a great book because
when he talks about legacy code is sometime
a Cobol or assembler or things like that,
it's coded, doesn't have test around it.
Because anytime you get in
that situation and you go to make changes,
at least I start to panic.
I'm like, I'm dealing with case history in my current job,
and these are people's livelihoods and legal things.
If I lose case history,
then I'm on the hook because
it's very important that you keep that stuff.
It's like, I don't want to make this change,
let's have test around it.
Again, it goes back to that courage.
It also makes your development faster.
>> Yeah. Tha sounds very likely.
>> Yeah. I've had a bunch of managers, not recently,
but early on in this whole testing phase,
are like, I'm not paying you to write twice as much code.
One particular customer,
I started writing tests and doing test-driven development,
but I kept it on a separate solution,
I never checked it into t If facets,
shows you how far it was.
What happened was my code and
had less and less defects than other developers codes.
What I mean by defect,
it's not varying forth to what
customer expects as well from what I expected to
do and things that I was
changing I wasn't having a side effect breaks.
As I was also consultant,
what happened was I started getting the project manager,
again showing you how old this project was,
kept coming to me with more important stuff
and you have to ease we're getting mad.
The full-time employees, your like why is,
the consultant getting the good stuff.
I said, well, in the PM side,
well because his code works,
which put me in an awkward position.
But then they came over and they said,
what are you doing differently?
I said, you might get in trouble.
I might go but your an FTE, do you want me to show you?
He said yes, and so I showed him.
How I was doing the test-driven development and how I had this
over here and I was checking the code and
making sure it wasn't breaking other things.
They actually went to management petition
them and they got tests allowed.
I took everything I had brought it in and we did some lunch and
learns and it's actually started implementing testing into it.
It was faster because first of all, your writing,
especially if you are doing test-driven development,
I know we're going to talk about that
later or maybe this episode,
I don't I remember how we planned it.
But you're only writing enough code to make this story pass.
Let's go back to the password complexity,
I'm only writing enough code to validate the password and
not writing the password history
and not writing these other things,
just enough code to make it pass.
I'm lesser focused as a developer, which helps.
Because we tend to go, squirrel, squirrel,
squirrel, and all you need
to fix this and we stop and then do it.
You see running in smaller increments of
code and you're only writing enough code to make the test pass.
As developers, we tend to gold plate,
we tend to say, they asked for this,
they're going to ask for this,
I'm just going to write it now.
Then all we're going to ask for this thing too,
and now I've got a whole bunch of code they never asked for.
I've taken time to build now we have to support it,
it's a potential surface area for defects.
Now I'm slowing down development.
>> Cool. What we're going to cover in this series
is how to automate your testing.
You've done a good job of
summarizing not only why is testing important,
but basically the more you do and the easier you make it,
the more you're going to do and then that password thing,
if you could write the code and then
automatically run a test that you have a list of
100 different things that people can enter
and you run your code against that automated test,
when you get to the point where all hundred of them pass,
you know your code works.
>> Correct.
>> It's pretty exciting that is going to help you
get the code right the first time.
It might take you 10 times to write it,
but the first time you check and show it to anybody else,
that works, that covers everything anybody could think of
and now you're the guy whose code works.
>> There's one more thing we didn't cover
and that's behavior testing.
There was a project I had,
it was the shortest consulting gig ever because I went down,
it was a bank and they had a function where they
wanted to get all their existing customers
and all their products and
then all the products their customers had and basically build
a Venn diagram of who didn't have
what product and give this to their salespeople.
They're doing all of these get all,
get all while they had nested them.
They got all the customers,
they got all the products and they got
which customers have which products
and it worked great on developer's machine.
Then it went into
the integration environment. It didn't work as well.
But it worked, so they released into production it brought
their servers down, stackoverflow.
They brought me in and I'm looking and I'm going,
if we just move these three GetAll outside of the for loop,
I think that fixes the problem.
We did that and sure enough it fixed a problem.
One thing we can do with moq,
which is a mocking framework,
and we have at least two episodes on that,
is we can set to behavioral expectations.
I want this scene to run but only once,
and if it runs more than once,
then you get an exception.
We can also check the behavior of our code,
not just a static analysis of this is password,
pass or fail the test,
but do we actually call
the logic to check the password or do we just accept it,
or do we comment
that out by accident because we were testing something.
>> Yeah. That's cool because once
you reach the public and then it's
starting to have those issues
that maybe weren't accounted for beforehand.
But I feel like that's when it gets really stressful,
to figure it out before things
start to crash and burn from a customers desk.
>> Yes, and we're doing an upgrade from web forms to.Net core
or.Net now and there's
some very complicated logic that we have and so no tests,
I inherited this code and so what we're doing is we're writing
moq behavior test around
all the existing code so that when we do write it,
for.Net 6, any ef Core
and SQL Server 2019 that were released check into behavior.
The structure of the code is going to be different,
but the interfaces are the same and we can use moq to make sure
that from a behavioral standpoint
we're doing the right thing in the upgraded version.
>> Great. Can't wait to get started,
which we will do next time on Visual Studio Toolbox.
[MUSIC]