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