Python for .NET Developers Transcripts
Chapter: Testing
Lecture: C# app under test
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
Before we see pytest in action and write unit test in Python let's see the equivalent C# version. Like all the other chapters, we have the C# version
0:11
and then we're going to create the Python version here. Remember our guitar project we were using in web and the database stuff?
0:19
Well, I took the essence of that core data access library and I put it over here and I called it lib and I made it
0:25
a little more proper and a little more official. It does logging and other things like that. So I didn't want to mess with what we were doing there
0:33
and I certainly didn't want to go into all the complexity of testing true web apps and stuff like that.
0:38
So I just copied it over here to keep it isolated. So the idea is, we're going to use this lib and by default
0:45
it uses this dependency injection style here that's like a super simple lightweight way to do dependency injection.
0:52
It just says if you can call the constructor with no agreements, 'cause there's defaults and if you do you just get the production database
0:59
and the production logger, but of course you can pass in something else for either of these. If you need to change its behavior
1:05
say for like, I don't know, a unit test. Okay, super lightweight dependency injection there. And then when we can just ask for all the guitars.
1:14
It's going to go and call this, get the guitars from the DB and this DB is the one that is past in right there.
1:21
If the styles are all of them, we return. Otherwise, we do a LINQ query to write them down. Another suggest LINQ to objects with some fake data here.
1:29
Again, we're keeping it a little bit simple. But if we look at this notice it's trying to indicate, hey, this is like
1:37
a proper data access layer faking going to a database. So it prints out this big warning. We're getting this from the database.
1:43
You shouldn't see it in a test, right? So lets just go and run this program. And it's running, Welcome to the guitar app.
1:49
What kind of guitars do you want to see? Let's see electric guitars. Boom, we found a bunch of cool electric guitars
1:55
from our database, but notice we're logging a message and the message is this. If I go like that it looks a little better.
2:02
And we're also getting stuff from the database. Now obviously we'd never do this in a real app but I put this huge over-the-top sort of
2:09
logging messages here to indicate these are dependencies that do not belong in a test, right? They're necessary for the app to run.
2:18
They're the real database, the real log in and so on. But the idea that you're suppose to interpret when you see that is, Oh, that's kind of a problem
2:25
if we were to try to test something and that dependency were still active. You could also ask for acoustic. Get our one acoustic guitar back.
2:32
You can see our message saying Hey, this is real app stuff, right? It's just there to mostly let us know that we're doing
2:38
the right thing if we could make those go away in the test. All right, so this is the application and it works
2:45
with this database that we got going here, right there. And the logger, I just threw it in the same files just to keep things a little less cluttered.
2:53
We have our logger and obviously it logs to the console and practices a private log to a file or maybe even to a database.
3:01
So our goal is that we want to test this library to make sure that it behaves correctly but we don't want to do so with the live dependencies.