No host has claimed this podcast yet, if you are the host you can verify ownership by claiming this podcast
© 2022 Brian Okken
154: Don't Mock your Database - Jeff Triplett
Test & Code in Python
Any test for your web app and it has a database what to do with the database during testing. Should you use the real thing or Market? Jeff, triplette says, don't mock it. Jeff is a partner at roces a director of the psf and president and co-founder of the Django events Foundation of North America. In this episode, we talked to Jeff about testing web applications pacifically, Django apps. And of course, talk about the downsides of database, mark, this episode is brought to you by David dog. And cat big cat. A big cat is a future flight service Beasley use flags in your coat with config cat. Libraries. Toggle, your feature Flags visually on a dashboard hide or expose features in your application without redeploying. Code set targeting rules to allow you to control, who has access to the new features that allows you to get features out faster. Test in production and do easy Robux with config cat, simple. A behind clear documentation, you'll have your initial proof-of-concept up and running and minutes. Whether you're an individual or a team, you can try it out with their forever, free plan.
Or get 25% off any paid plan with the code test and coat 2021 release features faster, with less risk with config cat. Check them out today at config cat.com.
Perkins testing code.
Hello, and welcome to Tessa and Cody. I am thrilled today to have Jeff triplette on. I've been following Jeff on online for a long time, but we never actually spoken. So this will be fun and we're going to talk about Django. Nothing things. So welcome, Jeff.
Hi Brian. It's good to be here. I'm a developer out of Lawrence Kansas. I work for revolution systems, which is a Django Consulting, python Consulting agency. I'm a partner there and I'm on the python software Foundation board. So I'm a director voted in by the community, which I appreciate being voted for and not voted for, and just appreciate getting represent people. I've also ran djangocon you with a bunch of organizers for the last six years, I started a nonprofit or co-founded a nonprofit called definite which is the Django events down dacian of North America. And then I also run a weekly Django newsletter call Django news with William Vincent who I think it's been under. So maybe before or one of your other shows he's involved with the newsletter with you keep people informed what's going on in the Django World, in Python news. And we just try to hit like the high points so that it's everything. So distributed in Django and python. It's kind of hard to find one spot. That kind of know what's going on with.
Run it and write it. So, I've been trying to like finished some of the automation pieces around like tweeting out links and stuff like that, which I think that probably go out today. So how did you get into working with Django? I think about 11 years ago or so. I was living in Southwest Missouri, and I was kind of looking at where do I want to do career-wise? Cuz I felt like I wanted to do more python development or more web and I was interested in startups and kind of side projects and stuff. And then I kind of happened on Ruby on Rails out of Chicago and I'd spent time in Chicago and really like Chicago and then I noticed there was a weird bloke called Django and out that blip on the map was in Lawrence Kansas which was only about a three-hour drive from where I lived in. So I noticed it was kind of funny because Matt Croydon and Simon Wilson who are both people, I really respected and read their blogs. For years were both like PHP developers and they both had switched over to Python and sell it one point I've ever seen Django.
I think I actually emailed Simon Wilson to say, hey, have you seen the school framework call Jango? And I had no idea that he was one of their life co-creators of it. And so, I don't know if Simon if he ever listen to this, if he has that email still there, I don't remember you replied or not. But I applied for the job to come work at the Lawrence Journal-World. I didn't get the job, but they told me, you know, try back in a year or something will probably be hiring again. And I think about like 11 months 12 months to the day, I got an email from him and said, hey, if you're still interested since you know what, your local, and you know, applied and came to work here and work for the newspaper for probably 3 years ago. One of the newspapers other companies. This World VBS before felt the Django people to work on newspaper software. And so I came to work on was called Ellington CMS, which was kind of the second, I think Jango app. It was definitely the biggest for the time and then three years later, I left to come work with Frank Wiles and a Jacob Caplan Moss, who was another creator of Django at work.
They invited me to come work with us and so I've been working with them for the last. I think 11 years or 10 years. I like that. And they asked me to be a partner a couple years ago. So sweet, sweet, love, you Django. Probably half of my, your last year was writing class code, so I don't just do Django code. It's anything and everything in Python Django, director of operations, for an ISP in, but I actually left the company. I was working in ASP and Microsoft, the world. I'd let that company to do peach be kind of side work or Contracting and then a group where they were turning to ice tea and they invited me to just basically join them cuz they had servers and they're like, it's pretty easy to scale, Peach be on Linux server so why don't you come join us? And then part of the time you can help us write software for the business and the other half. Then, you know, you can work on creating a Consulting agency or being a bringing basically like web applications to the Joplin MO.
Metro area. And so I did that, and three, four months later, they made me director of operations, and then I end up running. Nice, be for 5 years. So in part of my, like, hobby, at the time, we we ended up like, switching over to Django and python at the time cuz you know, I was pretty good with PHP but it's kind of tough. The right server scripts and stuff with it. It's much easier to write me to python just works better. I feel like if you can run it from the console level. So he's slowly started switching. The ice, be over, no more Python and Django Campbellton at the time. It wasn't a great framework. There was a lot of magic. So when Jango had the magic removal, that's when it really hit my radar as this is kind of perfect because I don't have to write admin code which means it's easier for people that you know, input data who is interest? Me and so are staffed and like we're gone you know, date of projects and stuff that we had and we ended up running like a news portal for Joplin for a while and so what kind of Grew From there? So I like being over the years but you know,
Going to happy to do whichever now are you still in Kansas Kansas at Lawrence Journal-World group Lindsley. Who wrote Haystack? He actually moved to Seattle and move back here so they're still some Django people from like. You know, that worked in that era, still around. Here is your job now. I mean to work from home, or to Kevin office, we do have an office. That's probably seven blocks from my house. I think I've been to it three times in the last year and I got a three-year-old and like with all things with covid-19, mostly work from the home and stuff like that. Cuz I have this thing about testing I think it's a good thing and you wrote something on Twitter saying something like by the way, don't ever mock your database or something like that. So I wanted to poke that. I mean, how do you feel about testing with Django and and why did he need to tell people to know?
A database. So is a consultant. I see a lot of good and misguided and I see a lot basically. And so I think I stumbled upon a client who is doing a lot of database mocking and this is a code basic kind of older. So it's a time, you know, 10 years ago is Schlitz, say something that people encourage because the doctor wasn't a thing back then, there wasn't prevalent. So the building has been up, like post-grads are my sequel boxes on the Fly and connect to them, was kind of slow. And so I think because it was a lot harder to configure for a while. We started seeing people who were mocking up their databases I think now there's just no reason to do it. I think it's more complicated. It's harder for me like I think there's an inn for one like I guess I don't want to just say my walking is bad like mocking can be really good and so I guess for me the Lions for mocking is like resource boundaries like if you're going to write code that uses Bato mean, you're going to connect to S3.
Then it's kind of hard to write test and if you have a team of developers you don't really want to distribute Teske's and have people writing test which right S3 and then everybody has to have their own buckets and their own credentials. So like using a library called motto is a really good way to mock-up S3 and Amazon services in general AWS services. So I think it's really good because, you know, you can actually write to it, you can say, queer data, can go, you can verify that things would have gotten saved S3 if you have the right credentials and it's just a really nice library to work with. And I think the other kind of like anything to do with certain types of State like with time zones daytime stamps, I think you know freezing or mocking. Dates has is a really good way to test. I did have a client issue not that long ago where they didn't have data loaded for daylight savings time for this year, but they had a lot of tests that looked at like being to three years ago is daylight savings time and end.
Find like predict that in different dates in so your testing pass dates, present, dates, and future dates. I think those are really good applications to mock, you know, that way you'd cuz you just don't know what's going to happen. When you're doing your test, try to run at watch February 28th at midnight to know, is there going to be the next day of February? 29th, or not?
yeah, I receive some some
I know user interaction happens over the boundary of the day. What happens to that things like that? Exactly. This is now and yeah, I just think it's just a lot of overhead of what I see is a lot of drifts that happens where people will write a letter of mocking and then they'll add new features to their codebase run their tests. And after a while when they bought their databases, the mocs no longer reflect the actual code and what's happened on the servers. And so, I've seen it, where it feature can be like, five lines of code, but then they may have to overhaul fifty lines of code to basically make the mocks happy. So, when you remove them oxen test against the database, these problems don't exist. And so I would avoid that drift and in general, you know, like if it's a distributed database like maybe I don't know if mongodb you would even matter. But like if you consider S3 remote database or something because of how you're saving the objects mock, those kind of things for sure. But post,
Jana. There is ways to speed up the test of that you don't have to worry about, you know, performance issues. When running them all of the unit test advice in the world, don't touch the database and don't touch the file system and things like that.
I guess I don't really read that much about best practices of database Maki and I don't like being able to test isolated areas, but to me, that's kind of a function call as well. So, you know, testing individual pieces. I agree. And I believe in integration testing and enough for the most part, like I'm more of a performance testing person. So because being a consultant, people usually called because they're having some major issues like why is her homepage taking 5 Seconds to run. But other other pages on the website may take a second and so you know what we do is? Look at that and break that problem down to see why I like real world. This happen once and somebody had what's called a Django middleware which is like functions to call. Every time I request is made and they were hitting the database and pulling up and look up table to had a quarter million records in it every single time somebody pulled up their homepage and so things like that by looking at performance testing in measuring the number of database queries that happen every time that that home
If you get that very quickly revealed that you have this big table and why do you want to load this for every single request? And so those issues are kind of fun. The find and Dino and I do believe in testing. So if clients are seeing the, don't test much have hidden performance issues, they just don't know about because they don't have the metrics to see where they're coming from.
This episode of testing code is brought to you by. Datadog, do you have an application that is performing slower than you like? Do you know why request have high latency with datadog? You can find the root cause fast troubleshoot your apps for Foreman's, but dated dogs into end distributed tracing and continuous code profiling to quickly detect what happened and why down to the line of code and in one click, you can correlate individual request with related logs and infrastructure metrics to get full stack observability with zero contact switching. Start tracking the performance of your apps with a free trial at Tustin. Khou.com datadog and datadog will send you a free t-shirt. And to be honest, my dude dog, t-shirt is one of my favorites. I wear it all the time.
If I don't mock the database, then do I use the live database or is there some other old alternative?
I like to use pytest fixtures and I'll create fixtures on the fly. If it's just kind of get a bad rap. I think I think pytest really reinvents maybe your reinvigorates pictures because like an early Django days, what was common practice for best? Practice was the use a bunch of Json files that you would load up and type. S pictures, have the right level of granularity that you can say, you know, give me one object or give me a thousand objects and be able to test against it pretty quickly. So that's what that's my go-to is pi test pictures. That mean I have a test that uses a fixed. Sure that fixture goes out in and spends up a small database or something and Thursday Tinder. What do you mean? So a database. So it'll be a local database if you depending on the size that we might like instead of you sending on this cash, we might use it in memory cache that way, you know, your rights are really fast and so yous.
The first couple of seconds of any tests we are right, that might be what loads of database fixtures, some of those get written to the database. Some of those are just on demand so you can pull up an object. It will give you everything - hitting save on the object, the Django so that you can hit that object and you'll run functions against it. So like if you're testing some logic like maybe a property or something that needs to calculate something that's on the fields but doesn't need to have the database. I'll just use one of those pictures and not save it cuz he can do the calculations based on seeing the fields themselves. If I need to save it, I mean, I can do thousands of tests and a minute. So I had to me, that's kind of the line. Is this, my test, we take more than a couple of minutes to run then, let's see what we can do to maybe, you know, isolate some of the tasks, or look at the pictures to see. You know, what am I loading? Too much data. That's kind of my my general use cases. How do we keep this under a couple of minutes? So you have like maybe a mixture that loads, some live data locally in a database. And in maybe,
Speed it up, you can use a memory to a memory database. And then you just have a whole bunch of tests that are using the same database. Then nice things. I think I don't really dress too much. Is the performance aspect? It's usually the I get brought into a job because somebody has something, you know, sometimes have a test. And one thing I like about pytest is being able to mark test based on time and say, like slow test or any test to take over a second and then immediately isolating nose. And then we kind of know what we need to work on. The other part is let's say the client only has about you know 30 40% test coverage. And so one thing I like to do is go in right? Just very loose tests around like all of their user, all the rest apis that really just calls, you know, calls the endpoints even if it doesn't have enough data and if it requires a 500 error or a 404 error or whatever the point is just to like live.
It's a 10 point to get some kind of response from it and then do an assertion on what those those response codes are and then that way we at least have some coverage when you look at coverage, of course, they know that we are at least touching his many aspects of the code base as we can. And then from there, that's when I put the marks in to say these are slow test to take over a second. Sometimes these will be 27 second test and nobody really understood like why does one test take longer cuz they don't really measure it and then from there we come back and start looking at like why does it take awhile? Is it you know probably if it's taken 27 seconds, it's trying to access them outside, web service or an internal web server its timing out and you just can't see it. And then from there, you know, we can start making the terminations of, you know, maybe for tennis we should time this out after half a second or a second, and we can start assessing like what's going on here. Another round, I like to do to you. I was just seeing, if a client, says like using my last one is like the bread and butter of their application, and this could be a vegan butter. This can be gluten free bread. Like,
Take for your condiments, are you know, what, size of choice and basically, you know what, what is the area of your code that your main business logic? Like what, what's, what's paying the bills? It's probably not going to be your about page, but there's probably some core functionality. That's why I'm going to go back then and start peppering the like a certain time queries calls and stuff. We're looking at the actual database calls and those of the tests that we're going to start with and we're going to fill in the actual fixtures to make the data look live and then measure what's going on inside it parts of your system, that makes sense. And and it's completely valid to say the parts that the reason why people use my software is this thing that thing that's to work then. So test more around that. Then around things like, you know, saving to Excel or something like that. Exactly, that's what we want. Like you're 80% test coverage.
Is what were you make your money? Then you know, it's probably okay to have, you know, 20% or 40% test coverage there like it's his party. Why it's probably not worth the time and money to like prioritize putting test their versus, you know if the part that pays your bills or were you accept transactions? If you have to like princess a higher transaction area something that's like I don't know, a service that people are using needs to be fairly fast. Also, where is a PR contact for him? Is okay if it's a little lagging because people just sitting there waiting for it to show up anyway, so good as a consultant. So you see a lot of different testing Styles then probably are a lot of people embracing pytest with Django testing and with other testing or is there a lot of unit test out there still. Where I feel like the people who haven't moved over from python to python3 of kind of got the message? Like it doesn't really work anymore.
Should I clean new versions of python to seven anymore? So I'm seeing a lot of old unit tests more and more but thankfully running pytest to bootstrap. Those is not bad. It's a pretty decent experience. So getting people to Pai test is kind of the first thing I do 90% of time, I can just install pytest. Make a couple of canned food while I can figure of high-test i&i file and just run inside. So I do see about 50% old unit test but, you know, most of that is just just because of this. I think wave of people that are decided that you know, how long we want to run a python to now that it's not being maintained anymore.
I feel like it's got to be a good. I mean, if you care about testing, I thought that's where a lot of the articles are being written, now is about pytest. So yeah. It took me kind of a wild Embrace pytest. Maybe because I didn't understand the way the sum of the plug in architecture work. So it was a little weird, like, writing a test function and using arguments that I didn't know where those came from. But once I kind of wrap my brain around pytest fixtures, are I really like how it works? No. Do you recommend people like rewrite? Their unit tests? If they if they already have like an existing set of tests or just run those with play test,
I would run those with and I think it just kind of depends on where they're at in testing. Like if they already have good test coverage, I don't really believe the code Gratis gathers, dust or Moss is against older. So I am probably doesn't we may not be worth it from a business perspective or justifiable for them to rewrite everything. But I think is you write new test or is you touch old Tess it's especially because of that functional design in most fight us. I don't think it's. I think it actually kind of makes things easier.
Lacey Williams info, I think you had on a while back. We worked on, we were over cuz you were supposed to and we were contests and depraved the eyes and stuff together. And at one point, we decided just to switch everything from kind of that. Classic unit test dial to just appear of Pi Pi, test dial and she absolutely hated it and kind of curse my name I think for the first, like, couple of days of it. But then after some time we look back and go actually that wasn't too bad. And so those tests kind of, save me a couple months ago and I couldn't figure something out and I'm trying to wrap my head on, you remember what the problem was? But I couldn't wrap my head around either author, some piece of it and I went back and looked at the status and sure enough likely seek and figured it out and that was like a huge time that you have time saved for us. So we've been testing the Django. I know the Django has invited us has this way where you can run you kind of, don't, you don't have to run through the u p, the web interface then you don't have to run selenium or something I can run, I can hook right into the Django guts and run locally.
Once you get in the hang of it, you don't really you don't really need to go back and manually test this much, you still should like these for healthy things to do but you never rest, apis and stuff. It's it's it's kind of a solved problem. I guess, I guess I'm for rest apis. Definitely for is that in? Is that where your time is often spent or you testing things that have like at what pictures to look at 90% or more Django rest framework, or flask or probably passed, PPI more and more in the last, like, 4 or 5 years? I feel like those server-side rendering is really making a strong comeback, so I expect the next year maybe, you know, whether it's 2021 or 2022, I can already see you were more clients and more people are starting to get interested in maybe pushing back on having to know you don't have to have full-time jobs scriptive to do front-end work and maybe i o s dubs to do iOS apps and no Android apps to Android.
Bucket of the water and they're all walking like to seen everything dance around your browser and everything those types of applications. But if things switch to be more server side than whatever, that is 4 Pi test is what I'm going to look into and do more that Dom Style testing for, you know, seeing what the browser see you. Well, I'm glad that you can trust the web stuff without having to do this selenium style that just doesn't like fun to me, but maybe that's just me. I don't, I don't know that I think testing is necessarily fun, but I like that feeling when you hit the ploy with a reasonable amount of confidence that you can go get coffee or have a weekend, you know, the one I don't look testing. I love the the freedom and security maybe from a good test weed, that lets me know something is going to break or not break. At least the obvious problems. You
I'm thinking about databases again, the local databases that you run are they pulled from the live data or do you have a, like, some dummy data that you fill in, for some of the time? It's dummy data. I have had clients before that, we'll have some. Pretty sizable use cases, usually, the more of selenium type driven test. Those tend to rely on noticed on more like without copy client data to a staging server or they did at one point in time and then they tend to maintain those. So I probably every ten clients I have that are just generated data. They'll be one that has a really complex cuz like one of them was kind of a deal with a lot of encryption and a lot of like serial number type and Coatings. That was kind of hard to fake and have reasonable data. So I think what they did is they had a pretty good system around it, a fat found, irregularities and bugs, they can freeze that data and they would copy that down to their staging servers. And that's what we've run tests off at 2 and then that way you don't have to take it and stuff. So
Everything is secure of it. But yeah, they were using kind of real-world data to generate their big data and then keeping that data setup generating to faked it and there's a bunch of tools available to be the favorite. The user is my favorite. It's got a pretty nice API and does a pretty good job of generating fake data along with in a filling out the objects in a nice way.
I'll have to check that out.
Does it, does it work with Django models then or what's the model part? Come from?
Yeah, it's it's for Django models. Essentially, you know? It uses was, it called a faker and so figure you can use on anything. Like, Faker, I assume we're supposed to go out to me that figure is just you know, create a bunch of random first names. Last names, addresses, whatever. So they have integration with Faker with a template or something, and it'll give it a model, like Pastor Django model into it, or the string representation of the app in the model name and then it will generate as many day that you know, fake objects as you want Kool-Aid. That seems like it'd be very nice. I think this is a fun discussion so thanks so much for joining me today.
by the darkness, every once in awhile,
And if you want to find you on the web, where do they find you? I'm pretty vocal on Twitter at Webb ology. So you need to find me. Their website is Jeff triplette. Calm, which most people can't spell, but that's fine. Thanks a lot and I will catch you later.
Thank you, Jeff. Lots of great information. Thank you. Also to patreon supporters, join them at testing, co.com support. Thank you. Can feed cat for sponsoring release features faster. With less risk with can pick can check them out of canned, fat cat. Calm, try them for free or used code testing code 2021 for 25% off. Thank you, Deja dog, for sponsoring modern into, and monitoring and security inside any stack, any app at any scale? Anywhere, get started with a free trial at Tustin, co.com datadog and David, I will send you a free t-shirt. Those links are in the show notes at testing, khou.com, 154, that's all for now. Now, go out and test something.
Login to see and leave a comments
Albert Einstein said, 'If you can't explain it simply enough, you haven't understood it well enough'.Dr Andrew brings such simplicity to explaining the workings of the brain. It's actually a hacker's guide into our own brain. You are doing great service to humanity Dr Andrew.·7 likes·
BEEN WAITING FOR THIS. Thank you Andrew for everything you do. Youre a true hero to society for the research you do and for sharing it with the public.2 months ago·1 like·
I very much appreciate the podcast representation 🎉·8 likes·
I find these weekly podcasts to be super inspirational, they seem to always motivate me to look at my purpose. Matt not only brings in his personal life experiences but he delivers them in such a way that they are relatable.2 months ago·9 likes·
No host has claimed this podcast yet, if you are the host you can verify ownership by claiming this podcast