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.

Talk Python's Mastodon Michael Kennedy's Mastodon