045-testing-software-with-python.vtt

WEBVTT

00:00:00.001 --> 00:00:03.240
What is the role, the core purpose of writing tests for your application?

00:00:03.240 --> 00:00:07.180
Should you write more unit tests and fewer integration tests, or is it actually the other

00:00:07.180 --> 00:00:11.260
way around? You may have heard of the test pyramid with unit tests building the foundation.

00:00:11.260 --> 00:00:16.840
In this episode, we'll talk about a variation on that theme called the test column. We talk

00:00:16.840 --> 00:00:22.340
about this and more with Brian Okken on episode number 45 of Talk Python To Me, recorded January

00:00:22.340 --> 00:00:24.060
27th, 2016.

00:00:24.060 --> 00:00:53.280
Welcome to Talk Python To Me, a weekly podcast on Python, the language, the libraries, the

00:00:53.280 --> 00:00:57.900
ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter

00:00:57.900 --> 00:01:02.820
where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm

00:01:02.820 --> 00:01:05.360
and follow the show on Twitter via at Talk Python.

00:01:05.360 --> 00:01:11.320
This episode is brought to you by Hired and SnapCI. Thank them for supporting the show on

00:01:11.320 --> 00:01:15.880
Twitter via at Hired underscore HQ and at Snap underscore CI.

00:01:15.880 --> 00:01:21.320
Hey, everyone. I hope you're looking forward to an interesting conversation on testing software

00:01:21.320 --> 00:01:26.780
using Python. This week, our guest, Brian Okken, is giving away five copies of his Python testing

00:01:26.780 --> 00:01:31.520
frameworks book. If you want to be in the running, be sure to visit talkpython.fm and enter your

00:01:31.520 --> 00:01:36.080
email address to become a friend of the show. Now, let's get right to the interview with Brian.

00:01:36.080 --> 00:01:37.900
Brian, welcome to the show.

00:01:37.900 --> 00:01:38.960
Hey, thanks, Mike.

00:01:39.200 --> 00:01:45.760
Yeah, it's really great to have another podcaster and a friend and a fellow Portlander here all

00:01:45.760 --> 00:01:49.220
together on Talk Python to talk about testing in Python.

00:01:49.220 --> 00:01:50.700
Yeah, I'm excited to be here.

00:01:50.700 --> 00:01:55.320
Yeah, yeah. It's really cool. So for the listeners out there who don't know,

00:01:55.320 --> 00:02:03.860
Brian is the host of Python Test Podcast, which is a fairly new, but how many episodes have you had?

00:02:03.920 --> 00:02:05.040
Are you on the ninth or tenth?

00:02:05.040 --> 00:02:08.300
Yeah, I can't remember. I think I did number nine recently.

00:02:08.300 --> 00:02:14.180
Yeah, number nine with Harry Percival. Excellent. Listen, that one, that's great. So I'll put a link

00:02:14.180 --> 00:02:20.860
to the podcast out there. So you spend a lot of time talking about testing and exploring sort of the

00:02:20.860 --> 00:02:24.900
whole spectrum or pyramid of testing in Python on your podcast, on your show.

00:02:25.380 --> 00:02:32.520
Yeah, I really want to cover... Actually, the podcast covers everything. I want to cover everything in

00:02:32.520 --> 00:02:34.260
software development and software testing.

00:02:34.260 --> 00:02:39.020
So we're definitely going to spend a good amount of time talking about that. But let's start at the

00:02:39.020 --> 00:02:42.060
beginning. How do you get into programming, Python, that sort of thing?

00:02:42.060 --> 00:02:48.460
Well, my first introduction to programming was in high school. I took a basic class.

00:02:48.460 --> 00:02:54.880
High school offered basic at Pascal, and I figured basic has to be easier, right? Because it's got basic in

00:02:54.880 --> 00:03:00.840
the name. But at the same time, I didn't really get into it too much then. But at the same time,

00:03:00.840 --> 00:03:08.440
I had a TRS-80 at home. And I spent a little time like typing in games from game listings from magazines,

00:03:08.440 --> 00:03:16.880
like Lunar Lander was one of my favorites. And then, yeah, I didn't do much more until college. I entered

00:03:16.880 --> 00:03:24.000
college intending to be an art and math major. And switched about two or three years in, switched to

00:03:24.000 --> 00:03:29.200
computer science. And then finished up with a bachelor's and master's at computer science.

00:03:29.960 --> 00:03:35.880
That's cool. So where'd Python come into the story?

00:03:35.920 --> 00:03:44.760
I learned C++. I learned all sorts of languages, Perl and C++ and others in college. I got a job at Hewlett-Packard doing,

00:03:44.760 --> 00:03:53.960
well, at first test systems and then embedded programming of instruments. And that was all C++ and still is.

00:03:54.720 --> 00:04:03.520
And then, I don't know, maybe four or five years later, I was in a group that had a Python test framework for testing,

00:04:03.520 --> 00:04:14.760
system testing the instrument. And started, that was probably maybe 2000, 2002. And I've been using Python for testing instruments ever since then.

00:04:14.760 --> 00:04:23.980
One thing that I think is interesting about that, a lot of times people feel like the programming language that the thing you're testing,

00:04:23.980 --> 00:04:29.200
the application or whatever is built in, that's the language in which you have to write the test, right?

00:04:29.200 --> 00:04:36.140
So if you're writing a C++ app, you have to fire up CPP unit and do C++ unit testing.

00:04:36.640 --> 00:04:42.520
That's not really what you're doing, right? Like you're actually testing code that maybe isn't Python, right?

00:04:42.520 --> 00:04:50.440
Yeah, it's all C++ and other languages inside. And we've got, but it's got a, the interface is available.

00:04:50.440 --> 00:04:56.460
Anything with an interface that's available from Python, you can use Python test frameworks to test them.

00:04:56.460 --> 00:05:04.120
And, you know, right off the bat, I had frameworks that the company gave me and didn't even think about it.

00:05:04.240 --> 00:05:11.780
But, yeah, it was probably 2010 when I started looking into other frameworks like unit test and pi test.

00:05:11.780 --> 00:05:19.220
Yeah, okay. So let's dig into a little bit of the type of stuff that you test at work, and then we'll come back and talk about your podcast a little more.

00:05:19.220 --> 00:05:25.900
So what exactly are you talking about instruments and physical things that you're testing?

00:05:25.900 --> 00:05:30.620
And these are written in what, C++ or like embedded systems with C++ or C?

00:05:31.120 --> 00:05:37.440
Yeah, it's C++. But these are, you know, there's lots of levels of embedded programming.

00:05:37.440 --> 00:05:45.260
There's, you know, embedded programming in like, you know, your car or your phone or your watch or whatever.

00:05:45.440 --> 00:05:53.700
But these are big instruments. These are, I don't know, they look like stereo components, but they're, they've got many processors inside.

00:05:54.200 --> 00:05:56.580
The box I work on right now runs Windows.

00:05:56.580 --> 00:06:03.460
So I'm really writing a Windows application, but I don't really do any Windows stuff myself.

00:06:03.460 --> 00:06:06.180
But it's all written in C++, all of my code.

00:06:06.900 --> 00:06:14.040
Yeah, the user interface, a lot of people use these for the boxes I work on are mainly used in production lines.

00:06:14.040 --> 00:06:25.840
And the production line control uses a, I guess, a string based, it's called Skippy, but it's a, it's a special language to control instruments with.

00:06:26.220 --> 00:06:30.640
Yeah, we, so that's, that's how our users control the box. So that's how we test them.

00:06:30.640 --> 00:06:39.320
Is that like for like managing factories? So if you're like building cars, like the machines, like put the door on or whatever, like those types of devices?

00:06:39.320 --> 00:06:41.040
Or what do you, what exactly are you thinking?

00:06:41.040 --> 00:06:54.320
Well, okay, so the box I work on right now is, is called the communications test box, one box tester, but it, so it tests all the RF, the transmit and receive abilities of a mobile phone.

00:06:54.320 --> 00:07:07.760
So pretty much, yeah, every, every phone that sells in the world has to go through testing to make sure it, you know, it does it, it, since it's a transmitter, it has to follow FCC rules.

00:07:07.760 --> 00:07:18.700
I see. So if I like lived down in San Diego and worked at Qualcomm, maybe I would buy your company's product to test the phone internals that we're building, something like that?

00:07:18.700 --> 00:07:28.800
Yeah. And anybody that's got, and any, we do not just cellular, but also like Wi-Fi broadcasting.

00:07:28.800 --> 00:07:35.240
So we do Wi-Fi testing and Bluetooth and anything that transmits and receives this box will test pretty much.

00:07:35.660 --> 00:07:46.900
Okay, cool. And so to test this embedded C++ app, basically, do you do some sort of C level interop with Python?

00:07:46.900 --> 00:07:53.500
And do you expose some kind of API that Python can understand? Or do you do this Skippy API against it? Or what's the story there?

00:07:53.960 --> 00:08:03.380
Well, so the magic that glues it all together is a library that's available on PiPi called PiVisa.

00:08:03.380 --> 00:08:16.580
So, yeah, there's a, Roden Schwartz and National Instruments and others have these Visa DLLs that you can use to interact, to send Skippy over LAN.

00:08:17.360 --> 00:08:29.000
And I use PiVisa to get at that. So it's really easy. You connect those up and you got to, you just have an object that you can send write and read commands to.

00:08:29.000 --> 00:08:30.020
Works great.

00:08:30.020 --> 00:08:36.640
Would you say that that kind of testing is sort of more holistic or is that more like unit testing?

00:08:36.640 --> 00:08:43.220
It sounds to me like my first guess is like you're kind of hitting the outside, like so maybe an integration test type story, yeah?

00:08:43.220 --> 00:08:45.820
Yeah, it's definitely like an end-to-end test.

00:08:45.820 --> 00:08:49.860
We test, I'm testing our entire system.

00:08:50.420 --> 00:09:08.180
But the kind of the, there is, so, you know, in looking at test frameworks, I'm way more interested in how the fixture model is because I use, we use setup and teardown to actually do things like, you know, move signals around and hit switch boxes.

00:09:08.180 --> 00:09:09.940
Definitely more of an end-to-end.

00:09:10.520 --> 00:09:23.340
But we do use ideas like mock, like if I'm testing the measurement capabilities, for instance, it's difficult to test that against a, like a moving target, like an actual mobile.

00:09:23.340 --> 00:09:31.760
So we'll have an arbitrary waveform generator generate a known signal and we test the receive side against the known signal.

00:09:32.440 --> 00:09:40.740
And then we can do the other end also, we send our transmission to like a different instrument to test it against something else.

00:09:40.740 --> 00:09:55.880
When you think of software architectures, you often hear people talk about things like dependency injection and basically managing and decoupling the dependencies of your software so that you can test the individual pieces, right?

00:09:55.880 --> 00:09:56.240
Yeah.

00:09:56.240 --> 00:09:57.300
Yeah, definitely.

00:09:57.300 --> 00:10:04.760
Yeah, but you, it sounds like your dependencies are more solid than, than maybe others, right?

00:10:04.760 --> 00:10:11.740
Like you've got physical devices and like scientific information coming in and, you know, like waveforms.

00:10:11.740 --> 00:10:14.360
And so you've, what kind of stuff do you do?

00:10:14.360 --> 00:10:16.700
That part actually isn't that different, really.

00:10:16.700 --> 00:10:28.040
I mean, because like on a, if you had like a big user database or something on a web application, the real, the real database on in, in the world is going to be a lot different than your like test database.

00:10:28.040 --> 00:10:32.840
So that's similar to how our real signals are different from our test signals.

00:10:32.840 --> 00:10:35.560
The diff, the difficulty is, is the fuzziness.

00:10:35.560 --> 00:10:45.780
So, we often don't really get, because even with a, a, a pure signal from a generator, we've got, you've got noise in the system.

00:10:45.780 --> 00:10:53.960
So you can't, you can't just get a, get a number out of a, out of a, a measurement and say, if it's 3.2, then it's correct.

00:10:53.960 --> 00:10:54.860
Otherwise it's wrong.

00:10:55.040 --> 00:10:59.700
And almost all of our measurements are, are, we've got tolerances around them.

00:10:59.700 --> 00:11:00.900
That's really interesting.

00:11:00.900 --> 00:11:09.320
a lot of people write software that is basically deterministic in, in ways that are easy to assess.

00:11:09.320 --> 00:11:19.040
So I get a Boolean back or I query for a user and the user is either there or they're not, or they're an, they're an admin or they're a regular user, right?

00:11:19.040 --> 00:11:21.300
These super clear distinctions.

00:11:21.600 --> 00:11:31.380
But when you get into sort of sciencey spaces, it gets really hard to actually just know, know that you're right.

00:11:31.380 --> 00:11:31.720
Yeah.

00:11:31.720 --> 00:11:37.820
I mean, if you get back a number and it's off by a thousandth, is that still the same?

00:11:37.820 --> 00:11:39.600
Does that count as okay or not?

00:11:39.600 --> 00:11:39.880
Right.

00:11:39.880 --> 00:11:41.180
That, that can be really challenging.

00:11:41.180 --> 00:11:41.800
Yeah.

00:11:41.800 --> 00:11:43.900
But there's, I mean, there's, there's ways to do it.

00:11:43.900 --> 00:11:51.580
We've got, we, we can, there's, we can split the, we, when we're testing the entire system, it's difficult to tell because it, you know,

00:11:51.580 --> 00:12:08.000
if it's off by 10%, it's hard to, you know, visually know, but, but we can, the actual numbers that go through the system go through, you know, there's, there's the different pieces are, are tested with different rigor.

00:12:08.180 --> 00:12:09.520
So it all works out.

00:12:09.520 --> 00:12:09.840
Yeah.

00:12:09.840 --> 00:12:11.040
That's an interesting point.

00:12:11.040 --> 00:12:25.340
And I'm, I'm actually not, I'm not the guy that, that tests the box to make sure that the, that it like actually, like if we say we're putting out like minus 10 dB, that it's actually really 10 dB, minus 10 dB.

00:12:25.600 --> 00:12:28.940
That's like some other guy in, in like a manufacturing facility.

00:12:28.940 --> 00:12:35.440
I'm, I'm mostly concerned with that, making sure all the heart, all the software didn't muck things up.

00:12:35.440 --> 00:12:45.220
So, in, in the end, I trust that the hardware is working correctly and I just want to make sure that the software hasn't mucked up the pristine hardware.

00:12:45.220 --> 00:12:46.580
Right, right, right.

00:12:46.580 --> 00:12:50.820
So you assume that the hardware you've got is actually processing everything.

00:12:50.820 --> 00:12:51.180
Okay.

00:12:51.180 --> 00:12:55.380
But you've got to gather it, save it, interpret it, all that kind of stuff.

00:12:55.380 --> 00:12:57.800
And so you kind of start at that level, right?

00:12:57.800 --> 00:12:58.540
Yeah.

00:12:58.540 --> 00:13:10.700
And then the measurement data that we're turning back, I mean, we're, we're sending back, we've got like thousands of different like measurement points that we're sending back and making sure that we don't muck one of those up.

00:13:10.700 --> 00:13:13.840
And then we don't put some, some array in the wrong place.

00:13:14.120 --> 00:13:17.120
that's, that's the sort of stuff that I'm really concerned with.

00:13:17.120 --> 00:13:19.100
Yeah, that's interesting.

00:13:19.100 --> 00:13:23.940
One of my first jobs was working at a place called eye tracking, Inc.

00:13:23.940 --> 00:13:25.400
eye tracking.com.

00:13:25.400 --> 00:13:33.440
And we would build these scientific visualization tools and sort of data analysis on top of eye tracking data, right?

00:13:33.440 --> 00:13:36.700
Pupil dilation over time, where you're looking, that, that kind of stuff.

00:13:36.700 --> 00:13:43.440
And we would end up doing really complicated math sort of pipelines on it, you know, Fourier analysis,

00:13:43.800 --> 00:13:45.520
wavelet decomposition, those kinds of things.

00:13:45.520 --> 00:13:51.040
And you try to, you know, test the results of one of those things, you know, it's super hard.

00:13:51.040 --> 00:14:03.100
So we basically would come up with a reference input and a reference output and go, if the deviation from, from this graph to that graph is, it's not too large, we'll call it, we'll call it the same, right?

00:14:03.160 --> 00:14:07.900
Because the, maybe they use something like MATLAB to generate the reference results.

00:14:08.080 --> 00:14:13.640
And, you know, the way it deals with floating point numbers might be slightly different than the language we were using or something like that.

00:14:13.640 --> 00:14:14.540
Yeah.

00:14:14.540 --> 00:14:20.160
It's an interesting challenge that I think a lot of people building, I don't know, more standard business apps.

00:14:20.160 --> 00:14:21.920
It doesn't really get on your radar, right?

00:14:22.000 --> 00:14:24.700
Because the user is either an admin or not.

00:14:24.700 --> 00:14:26.040
You know, assert true, done.

00:14:26.040 --> 00:14:27.200
Yeah.

00:14:27.200 --> 00:14:33.000
I mean, actually, people that have that sort of a test job, I'm like, what's so hard about this?

00:14:33.000 --> 00:14:35.420
Just, you know, write the test and get on with life.

00:14:36.380 --> 00:14:36.580
Yeah.

00:14:36.580 --> 00:14:37.440
So, okay.

00:14:37.440 --> 00:14:42.160
So let's, let's look at some of the frameworks and get some of your thoughts on that.

00:14:42.160 --> 00:14:48.220
So let's say the majority of people listening know what unit testing is, what the goals are.

00:14:48.220 --> 00:14:54.120
But I know a lot of my listeners are sort of scientists getting into programming or new programmers.

00:14:54.120 --> 00:14:57.160
So maybe give us just the elevator pitch.

00:14:57.160 --> 00:14:58.340
What is unit testing?

00:14:58.340 --> 00:14:59.120
Why do we care?

00:14:59.120 --> 00:15:02.360
I'm not sure why we care about unit testing, actually.

00:15:02.360 --> 00:15:05.260
Or software testing, rather.

00:15:05.340 --> 00:15:18.020
No, so that, that's a, the phrase unit test is a, is one that's kind of a, a sticky point for me because the, in extreme programming, the, they use the term unit test.

00:15:18.020 --> 00:15:23.840
And that just meant any developer test, anything written by developers, not written by the QA team.

00:15:23.840 --> 00:15:27.840
And, and in a lot of communities, it's stuck with that.

00:15:27.840 --> 00:15:31.420
It is, that's the use model.

00:15:31.520 --> 00:15:35.960
That's what a lot of people commonly term, term a unit test is something written by a developer.

00:15:35.960 --> 00:15:41.480
And then in the TDD community, that often isn't the definition.

00:15:41.480 --> 00:15:45.880
The unit test is often the smallest possible, like one function.

00:15:45.880 --> 00:15:47.460
You're testing one function at a time.

00:15:48.200 --> 00:15:56.200
And I look at, so there's the most importantly is that the entire, the entire thing is tested.

00:15:56.200 --> 00:15:57.680
Your entire software is tested.

00:15:57.680 --> 00:16:03.820
And unit testing is, I think there's certain places where you want to go in and test.

00:16:04.480 --> 00:16:07.220
I like to put tests anywhere where I have a promise.

00:16:07.220 --> 00:16:12.540
If I'm promising anybody other than myself that things are going to work right, we need tests there.

00:16:12.540 --> 00:16:19.400
So if I've got a, a library that other team, other team members use or other, other groups use, that needs tests around it.

00:16:19.400 --> 00:16:26.400
But the, and in your, anywhere there's interfaces, interfaces between groups or between components.

00:16:26.400 --> 00:16:28.140
Those are great places to put tests.

00:16:28.920 --> 00:16:31.300
And then of course the entire system function tests.

00:16:31.300 --> 00:16:43.060
I think the focus on unit testing, unfortunately takes some of the responsibility out of system level testing where I think it's unfortunate.

00:16:43.060 --> 00:16:49.140
I think there's different scenarios where things like unit tests matter more and other times they matter less.

00:16:49.140 --> 00:16:57.820
So times I think they matter a lot are when you have a lot of people all in the same general code base making changes.

00:16:58.200 --> 00:17:00.620
And you don't necessarily know everything that's changing.

00:17:00.620 --> 00:17:01.520
Right.

00:17:01.520 --> 00:17:12.020
So, so people are checking in changes and you're not necessarily, I mean, you're doing code reviews and stuff, but you're not necessarily like always aware like, oh, they actually changed this method that I was depending on.

00:17:12.020 --> 00:17:19.040
And they didn't understand this like implicit contract I built around the return value here or something like that.

00:17:19.040 --> 00:17:19.260
Right.

00:17:19.260 --> 00:17:19.900
Yeah.

00:17:19.900 --> 00:17:22.060
So I think it's really valuable there.

00:17:22.060 --> 00:17:28.160
And I think it's valuable for helping, helping build apps where fewer people are working on it.

00:17:28.160 --> 00:17:29.380
There there's less churn.

00:17:29.380 --> 00:17:44.240
But one of the things that I saw, you know, early two thousands and in response to the extreme programming was people saw that they, they thought they had to do, you know, 95% code coverage.

00:17:44.740 --> 00:17:45.920
Everything is TDD.

00:17:45.920 --> 00:17:49.360
If you don't start that way, it's bad software.

00:17:49.360 --> 00:17:50.420
You just can't write it.

00:17:50.420 --> 00:17:52.680
How can you possibly stand up for it?

00:17:52.680 --> 00:17:57.300
And, you know, over time I saw a lot of people saying, well, we can't do that.

00:17:57.300 --> 00:17:57.980
Right.

00:17:58.120 --> 00:18:00.700
We are in too much of a hurry or whatever.

00:18:00.700 --> 00:18:02.320
You know, they have whatever excuse.

00:18:02.320 --> 00:18:04.440
A lot of times it wasn't totally unreasonable.

00:18:04.440 --> 00:18:10.040
We basically say we can't match that level of commitment to testing.

00:18:10.040 --> 00:18:11.520
So we're not going to do any.

00:18:11.520 --> 00:18:19.120
And I think that that's one of the places where it can actually, that message of like test everything can become negative.

00:18:19.120 --> 00:18:23.640
Because, you know, if they had written, like you had said, the thing you're making a promise about, right?

00:18:23.640 --> 00:18:29.840
Like if, if you're writing like stock trading software, the part that actually says buy or sell, there should probably be tests on that.

00:18:29.840 --> 00:18:35.020
The, the part that logs that the app started probably doesn't need you in a test, right?

00:18:35.020 --> 00:18:39.080
There's lots of parts of apps that are just there to support some sort of core.

00:18:39.080 --> 00:18:42.560
And that core is much more important that it's tested, I think.

00:18:42.560 --> 00:18:43.740
And what do you, what do you think?

00:18:44.300 --> 00:18:45.000
Yeah, totally.

00:18:45.000 --> 00:18:53.160
It's like, I think, actually, I think you brought it up in one of your podcasts recently that, that it's the thing that, the thing that's making you money.

00:18:53.160 --> 00:18:55.180
The reason why somebody is buying your thing.

00:18:55.180 --> 00:18:57.580
That's what you should test the heck out of.

00:18:57.580 --> 00:18:58.900
Yes, absolutely.

00:18:58.900 --> 00:19:05.960
Like if, if, if that is your thing that you build for the world, that little essence of it, you had better test that, right?

00:19:05.960 --> 00:19:06.220
Yeah.

00:19:06.220 --> 00:19:09.400
But there's, as you know, you ship real software.

00:19:09.400 --> 00:19:12.520
It's like, that's like 20% of the code you write.

00:19:12.620 --> 00:19:14.440
There's 80% that isn't that.

00:19:14.440 --> 00:19:18.620
Well, and then I like, I like code coverage tools.

00:19:18.620 --> 00:19:26.440
But my, a lot of times I think that they're, instead of looking at the, there's two ways to get to 100%, right?

00:19:26.440 --> 00:19:31.040
There's a, you can either write more tests or you can delete code.

00:19:31.040 --> 00:19:33.640
I think you should delete more code.

00:19:33.640 --> 00:19:40.500
If you've got, if you've got a, a bunch of software that is not reachable from the user interface.

00:19:40.500 --> 00:19:49.220
If, if I can't make some section of the code hit that piece of code with, with normal user input, maybe it doesn't need to be there.

00:19:49.220 --> 00:19:50.700
That's a really interesting point.

00:19:50.780 --> 00:19:50.960
Yeah.

00:19:50.960 --> 00:19:51.440
Yeah.

00:19:51.440 --> 00:19:51.500
Yeah.

00:19:51.500 --> 00:20:04.740
This episode is brought to you by Hired.

00:20:04.740 --> 00:20:10.340
Hired is a two-sided curated marketplace that connects the world's knowledge workers to the best opportunities.

00:20:10.820 --> 00:20:17.840
Each offer you receive has salary and equity presented right up front, and you can view the offers to accept or reject them before you even talk to the company.

00:20:17.840 --> 00:20:23.580
Typically, candidates receive five or more offers within the first week, and there are no obligations, ever.

00:20:23.580 --> 00:20:25.140
Sounds awesome, doesn't it?

00:20:25.320 --> 00:20:26.800
Well, did I mention the signing bonus?

00:20:26.800 --> 00:20:30.180
Everyone who accepts a job from Hired gets a $1,000 signing bonus.

00:20:30.180 --> 00:20:32.980
And as Talk Python listeners, it gets way sweeter.

00:20:32.980 --> 00:20:38.700
Use the link Hired.com slash Talk Python To Me, and Hired will double the signing bonus to $2,000.

00:20:38.700 --> 00:20:40.840
Opportunity's knocking.

00:20:40.840 --> 00:20:44.260
Visit Hired.com slash Talk Python To Me and answer the call.

00:20:49.860 --> 00:21:01.100
I've spent more than once, I've been giving some big software projects and said, you know, have a look at this, and then we're going to need to have you help us add a feature or recommend some change.

00:21:01.100 --> 00:21:02.740
And there'll be like some method.

00:21:02.740 --> 00:21:04.440
I'm like, what does this do?

00:21:04.440 --> 00:21:07.260
What does this have anything to do with this code?

00:21:07.260 --> 00:21:08.700
It doesn't seem to do anything.

00:21:08.700 --> 00:21:15.000
And I'll like study the code and then, you know, two hours later, I'm like, oh, it's never called at all.

00:21:15.000 --> 00:21:15.180
Yeah.

00:21:15.180 --> 00:21:17.160
Somebody should have just deleted it.

00:21:17.160 --> 00:21:20.920
They should have just deleted it and the world would have been a better place.

00:21:20.920 --> 00:21:23.080
But instead, you know, I wasted two hours.

00:21:23.080 --> 00:21:24.480
Somebody else probably wasted two hours.

00:21:24.480 --> 00:21:26.460
And it just gets kicked down the road.

00:21:26.460 --> 00:21:33.860
The other thing, one of the things that I actually like, I'm writing more lower level tests than I used to.

00:21:33.860 --> 00:21:37.040
I used to mostly focus on high level tests.

00:21:37.040 --> 00:21:42.700
But the, and I still do, but lower level tests do have their place.

00:21:43.300 --> 00:21:48.840
But the, I like the model of, in test-driven development of the red-green refactor.

00:21:48.840 --> 00:21:51.580
But just don't forget the refactor part.

00:21:51.580 --> 00:21:59.520
So if a test, putting a test in place makes it so that you cannot refactor something, then maybe that test isn't quite right.

00:22:00.220 --> 00:22:05.440
I don't want to, I don't want to restrict my ability to change my mind and redesign something.

00:22:05.440 --> 00:22:05.880
So.

00:22:05.880 --> 00:22:13.900
I had brought up the, you know, the perfect being the enemy of the good sort of thing where people say, if I can't have really good test coverage, like what, what is it?

00:22:13.900 --> 00:22:14.820
Well, I'm not even going to start.

00:22:14.820 --> 00:22:15.320
Forget this.

00:22:15.320 --> 00:22:16.900
It's too much work to do testing, right?

00:22:17.320 --> 00:22:17.580
Yeah.

00:22:17.580 --> 00:22:28.300
Well, and that's, you see that a lot when, when a team like looks at, looks at their code and they go, they get a new manager in or a new, somebody comes in and says, hey, we need to add a bunch of tests to this.

00:22:28.300 --> 00:22:32.220
But where do you start when you have like a 10 years of legacy code?

00:22:32.220 --> 00:22:34.920
You can't just cover everything.

00:22:34.920 --> 00:22:38.480
So yeah, there's a, you got to just start somewhere.

00:22:38.480 --> 00:22:42.260
You know, I have a book recommendation actually, now that you bring that up.

00:22:42.260 --> 00:22:52.460
So there, you know, Michael Feathers is a guy that in the early days of test driven development and extreme programming and all that sort of stuff, he was really active.

00:22:52.460 --> 00:22:57.300
And he wrote a book called Working Effectively with Legacy Code.

00:22:58.180 --> 00:23:20.220
And it's, you know, given the time, it was a little more C++ focused, but it has some really amazing ideas of like, how do I take this app, which has a million lines of code and zero tests, and start carving out little epochs of code functionality that are supported by tests and ways you can do that that are safe.

00:23:20.220 --> 00:23:22.040
And definitely recommend it.

00:23:22.100 --> 00:23:31.520
If people are dealing with like huge apps that are not yet tested and put together in a way that makes them basically untestable, check out Michael Feathers' book.

00:23:31.520 --> 00:23:32.160
Okay.

00:23:32.160 --> 00:23:32.680
Yeah.

00:23:32.680 --> 00:23:33.620
Have you seen that one?

00:23:33.620 --> 00:23:34.960
Definitely.

00:23:34.960 --> 00:23:38.760
I've got a difference of opinion on that one, but I'll just let that go.

00:23:38.760 --> 00:23:39.500
No, no, no, no, no.

00:23:39.500 --> 00:23:40.080
I wouldn't hear it.

00:23:40.080 --> 00:23:40.460
Tell me.

00:23:40.460 --> 00:23:46.380
I think it just seems silly to try to add a bunch of unit tests to a bunch of existing code.

00:23:46.380 --> 00:23:52.240
I think it's way more profitable for your company to put functionality testing around it.

00:23:52.240 --> 00:23:57.140
And because they like the end to end functionality testing of your system.

00:23:57.140 --> 00:24:06.840
If, if you know, like you, you need to know if you're going to refactor something, you need to know that the end functionality is still working solid.

00:24:06.840 --> 00:24:16.500
And if you have tests in place to guarantee that, then what value is it to, to go in and add like thousands of unit tests?

00:24:16.500 --> 00:24:17.180
Sure.

00:24:17.180 --> 00:24:20.000
So I think that's a totally, totally valid point.

00:24:20.000 --> 00:24:25.080
And I think, you know, it's been like, gosh, it's probably been 12, 13 years since I read that book.

00:24:25.080 --> 00:24:28.660
So, you know, I'm, I'm going to only get it like a little bit, right.

00:24:28.660 --> 00:24:37.640
But I think the idea was like, suppose you've got some huge, you've got a library you're calling and like you hit the outside method, like some, you know, do your thing library.

00:24:37.640 --> 00:24:42.600
And it gives you an answer back rather than trying to set up a whole bunch of tests inside there.

00:24:42.600 --> 00:24:48.360
The question was like, well, how could I refactor some dependency or some bits?

00:24:48.360 --> 00:24:48.580
Right.

00:24:48.580 --> 00:24:53.860
So maybe what you do is you just come up with a bunch of inputs, save the outputs and go long as those don't change.

00:24:53.860 --> 00:24:55.000
We're going to call it good.

00:24:55.000 --> 00:25:01.680
It was some, some like really basic scaffolding to say the thing kind of looks still okay.

00:25:01.680 --> 00:25:02.740
Yeah.

00:25:02.740 --> 00:25:14.960
I mean, I think looking at, putting tests around the outside and then also looking at the different interfaces in the side of the system and, and maybe sure, maybe adding some different interfaces that weren't there before to try to separate the design.

00:25:14.960 --> 00:25:22.640
But all of that involves like a redesign and you're not going to, you're not going to guarantee that you're not breaking external functionality.

00:25:22.640 --> 00:25:27.780
It's just, it's just, they don't, they don't test for that.

00:25:27.780 --> 00:25:29.340
Yeah, that's right.

00:25:29.340 --> 00:25:45.840
So I think that's, that's probably an interesting thing to explore a bit is, can we be talking about unit tests and the whole extreme programming origins of it and all that, but there's kind of what you refer to on your show as like a pyramid of testing capabilities or functionality.

00:25:46.120 --> 00:25:47.120
Can you go into that a bit?

00:25:47.120 --> 00:25:48.080
Yeah, sure.

00:25:48.080 --> 00:25:55.440
Well, I don't really like the test pyramid, but if you, if you do much reading about software testing, you'll run into a test pyramid.

00:25:55.940 --> 00:25:56.640
All right.

00:25:56.640 --> 00:26:05.360
So the test pyramid, the notion, if you read in, do any reading on test software testing, you'll run across references to a test pyramid.

00:26:05.500 --> 00:26:16.260
So the idea is, a foundation of unit tests and some integration tests and very little functional tests, just end to end tests.

00:26:16.260 --> 00:26:17.440
And, um.

00:26:17.440 --> 00:26:17.620
Right.

00:26:17.620 --> 00:26:20.540
Kind of like a food pyramid where like the dessert is at the top.

00:26:20.540 --> 00:26:23.400
You should have just a little tiny bit and that's the functional bit at the top.

00:26:23.840 --> 00:26:24.280
Yeah.

00:26:24.280 --> 00:26:37.680
And, what, what, and the, there's the reason is because supposedly functional system testing is, doesn't give you much benefit and it, they break and they're brittle and they're fragile.

00:26:37.680 --> 00:26:39.500
I just don't buy it.

00:26:39.500 --> 00:26:44.040
and what, what happens I think is developers see that and they go, Oh, okay.

00:26:44.040 --> 00:26:48.380
Focus on unit tests and leave, leave the end to end test to QA.

00:26:48.580 --> 00:26:53.440
The problem with that big problem with that is a lot of teams don't have a QA anymore.

00:26:53.440 --> 00:26:56.660
So there's nobody doing end to end tests.

00:26:56.660 --> 00:26:58.500
Somebody's got to.

00:26:58.500 --> 00:27:01.620
so it's, if there's no QA, then it's your customers.

00:27:01.620 --> 00:27:05.860
And, I don't think that's the right person to do quality assurance.

00:27:05.860 --> 00:27:15.780
So I think that focusing on, maybe a column of tests, it should be a column, not a pyramid.

00:27:16.840 --> 00:27:18.780
Do, do the tests where they make sense.

00:27:18.780 --> 00:27:28.180
You've got to have full behavior coverage, end to end wise to make sure that your system works the way you promised it's going to work.

00:27:28.180 --> 00:27:40.420
And, and also like with, especially with, continuous integration, if you're relying solely on automated tests, those have to be promises that you're trying to keep to the customer.

00:27:40.800 --> 00:27:44.200
And then, I don't really know what integration tests are.

00:27:44.200 --> 00:27:47.480
There's a lot of definitions for it, but it's the middle part.

00:27:47.480 --> 00:27:52.180
And sometimes it's integration test means integrating with the outside world.

00:27:52.180 --> 00:27:55.920
So if you're integrating with a database library, it's tests against that.

00:27:56.020 --> 00:28:02.260
But then also some people think of, integration tests as between two components or between two functions.

00:28:02.260 --> 00:28:06.960
And then unit tests are the low level while you're designing your code.

00:28:06.960 --> 00:28:07.940
I don't know.

00:28:07.940 --> 00:28:10.380
I think that you just need to use your own.

00:28:10.380 --> 00:28:11.600
I don't think there's a rule of thumb.

00:28:11.600 --> 00:28:14.400
I think you got to use your judgment and put tests where it makes sense.

00:28:14.620 --> 00:28:19.360
I think that, yeah, I really feel that that's, that that's good advice, right?

00:28:19.360 --> 00:28:24.200
The whole, let's make, make the top part of the pyramid a little fatter and make it more like a column.

00:28:24.200 --> 00:28:24.940
Yeah.

00:28:24.940 --> 00:28:29.620
So I think that makes a lot of sense because let's say you have a thousand unit tests.

00:28:29.620 --> 00:28:31.340
I actually, I'm with you.

00:28:31.340 --> 00:28:35.980
I don't really know what an integration test is, but say you have a hundred of those and you're at 10 functional tests, right?

00:28:35.980 --> 00:28:42.440
Do you really need the thousand unit tests or are those 10 functional tests enough?

00:28:42.440 --> 00:28:42.800
Maybe.

00:28:42.800 --> 00:28:52.020
Well, a lot of the arguments for the, a lot of the unit tests are to make sure that, you know, somebody else doesn't break your units or something.

00:28:52.020 --> 00:28:57.140
But I don't know if you, I just think functional testing needs to be done more.

00:28:57.140 --> 00:29:00.380
So, well, you know what I think the origins of it are.

00:29:00.380 --> 00:29:08.060
I think it has to do with the TDD side of things like you, it's very difficult to functional TDD.

00:29:08.060 --> 00:29:10.560
I think it's, I think it works great.

00:29:12.080 --> 00:29:20.780
well, like, Harry brings it up and it's been brought up by others as kind of a double loop TDD where you, you start, start with the functional test.

00:29:21.000 --> 00:29:29.040
And then, and then, while you're trying to fix that functional test, that's failing, you write a bunch of unit tests.

00:29:29.740 --> 00:29:31.980
I think that works, works good.

00:29:31.980 --> 00:29:38.340
I just, you know, once you have the functional test working, do you need to keep the unit tests?

00:29:38.340 --> 00:29:38.740
I don't know.

00:29:38.780 --> 00:29:39.700
It's kind of up to you.

00:29:39.700 --> 00:29:46.020
I think keep them if, if they're not, I think of a unit test is like scaffolding, right?

00:29:46.020 --> 00:29:50.840
So if you're, well, you're, if it helps you to build your software to put a bunch of scaffolding around it.

00:29:50.840 --> 00:29:51.380
Great.

00:29:51.880 --> 00:29:56.860
But, once it's built, I don't know, some of the scaffolding can come down maybe.

00:29:56.860 --> 00:29:57.560
Yeah.

00:29:57.560 --> 00:29:59.040
You're left with_columns or something, right?

00:29:59.040 --> 00:29:59.740
Interesting.

00:30:01.420 --> 00:30:01.820
Yeah.

00:30:01.820 --> 00:30:03.940
I think that's a good way to look at it.

00:30:03.940 --> 00:30:10.640
I think one of the really big values that unit tests provide in to some degree, the functional

00:30:10.640 --> 00:30:17.400
tests and integration tests is they get you to think about how your function or object or

00:30:17.400 --> 00:30:20.280
API is used from the outside sooner.

00:30:20.280 --> 00:30:21.520
Yeah, definitely.

00:30:21.520 --> 00:30:25.980
And that, that's why I think focusing on interfaces, if you, if you're really building an interface

00:30:25.980 --> 00:30:31.040
that you need to have clean, then it needs to be, it needs to be changeable.

00:30:31.040 --> 00:30:36.900
But, and tested, but like if, if, like, so let's say I'm writing a handful of classes that

00:30:36.900 --> 00:30:42.160
all work together and I'm, I'm the main developer in this section of code, it's just going to

00:30:42.160 --> 00:30:42.840
be me, right?

00:30:42.840 --> 00:30:49.700
so if it, I don't think I'm going to put a unit test around every function because that

00:30:49.700 --> 00:30:55.520
means every time I want to refactor this system, I've got to change all the unit tests.

00:30:55.520 --> 00:31:00.660
As long as this, this subsystem works from the outside world.

00:31:00.660 --> 00:31:01.540
I think that's enough.

00:31:01.540 --> 00:31:06.380
I think one of the big mistakes that people also make, you know, in addition to being,

00:31:06.380 --> 00:31:10.060
letting like the perfect be the enemy of the good and just saying, well, we can't do perfect.

00:31:10.060 --> 00:31:10.820
So we're not starting.

00:31:10.820 --> 00:31:17.600
I think the other problem is that people write unit test code in a different mental state.

00:31:17.600 --> 00:31:19.520
Let's just say test code, right?

00:31:19.520 --> 00:31:24.180
Cause you know, it's, it's up and down the column that you're defining here.

00:31:24.180 --> 00:31:25.080
Yeah.

00:31:25.540 --> 00:31:30.920
So I think they write those in a different mental state than the core of their application.

00:31:31.600 --> 00:31:35.740
Like I've seen plenty of people just go to unit tests and just copy, paste, copy, paste,

00:31:35.740 --> 00:31:37.600
like 10 lines of code.

00:31:37.600 --> 00:31:39.280
And like, what are you doing?

00:31:39.280 --> 00:31:41.920
Like, would you do that in normal code?

00:31:41.920 --> 00:31:42.780
Of course you wouldn't, right?

00:31:42.780 --> 00:31:46.080
You'd make that a function or some sort of object or something.

00:31:46.080 --> 00:31:46.360
Right.

00:31:47.040 --> 00:31:55.100
But that makes it way more painful to refactor or evolve your code when you've got 20 copies

00:31:55.100 --> 00:31:56.440
of the thing that you have to maintain.

00:31:56.440 --> 00:32:00.840
Well, yeah, that's another reason why I think you had to be careful with the whole, like,

00:32:00.840 --> 00:32:06.320
have a, have as many unit tests as you can write in a day because it's, it's an, it's

00:32:06.320 --> 00:32:10.220
a code asset, but it's also, it's also a, it's a weight around you.

00:32:10.220 --> 00:32:13.100
You've got to, you've got to keep it all the time and you've got to change it.

00:32:13.100 --> 00:32:14.260
It's, it's code maintenance.

00:32:14.540 --> 00:32:17.680
There's test code maintenance just as there is normal code maintenance.

00:32:17.680 --> 00:32:18.280
Yeah.

00:32:18.280 --> 00:32:20.060
So I think you can structure your test code.

00:32:20.060 --> 00:32:25.720
Most people's test code could probably be refactored to be way more maintainable.

00:32:25.720 --> 00:32:28.760
And so that's good, but, and people should do that.

00:32:28.760 --> 00:32:31.560
But like you say, like more is not always better.

00:32:31.560 --> 00:32:36.600
I think if you think of what are the main use cases that a user is going to do with your application,

00:32:36.600 --> 00:32:42.540
if you can test those, chances are all those little edge cases that you're testing, if they

00:32:42.540 --> 00:32:48.160
were to go wrong, your main user stories or whatever don't really work anymore.

00:32:48.160 --> 00:32:48.500
Right.

00:32:48.500 --> 00:32:50.100
So do you have to write those little tests?

00:32:50.100 --> 00:32:51.520
That's, that's an interesting question.

00:32:51.520 --> 00:32:57.300
Well, I think that if, if a user, I, all the edge cases from a user's perspective, from

00:32:57.300 --> 00:32:59.760
like an end user, those should be tested.

00:32:59.880 --> 00:33:05.320
I definitely think you ought to test the edge cases, but the edge cases of

00:33:05.320 --> 00:33:06.300
every function.

00:33:06.300 --> 00:33:08.720
I don't, I don't think so.

00:33:08.720 --> 00:33:14.060
If you've got like, like a, one of the examples I've given before is if I've got a, a username

00:33:14.060 --> 00:33:20.160
that goes through the system and in some, some function that has to intercept that takes a

00:33:20.160 --> 00:33:20.740
string then.

00:33:20.740 --> 00:33:21.040
Right.

00:33:21.220 --> 00:33:25.840
So do I need to test to make sure that string can handle a thousand characters?

00:33:25.840 --> 00:33:27.740
maybe not.

00:33:27.740 --> 00:33:33.620
It's interesting to question these assumptions about, you know, how many tests should you have?

00:33:33.620 --> 00:33:38.700
How, how should they, should they be in a pyramid where it's, you know, decreasing as you go up

00:33:38.700 --> 00:33:42.140
or should they be kind of more flat and so on?

00:33:42.720 --> 00:33:46.040
Well, the, it's, it, and it's, it's sort of theoretical, right?

00:33:46.040 --> 00:33:50.780
Because it just, it changes with every situation and the tests need to be an asset so that you

00:33:50.780 --> 00:33:57.340
can, if they need to be such that you can trust that if the tests pass, your code is good and

00:33:57.340 --> 00:34:02.220
whatever the tests have to be so that you can trust that you can check something in and it's

00:34:02.220 --> 00:34:07.240
good because the tests pass, that's where you need to be, whatever it takes to get to

00:34:07.240 --> 00:34:07.500
there.

00:34:08.040 --> 00:34:08.160
Yeah.

00:34:08.160 --> 00:34:14.320
And related to that is if you have tests such that it takes 15 minutes to ask the question,

00:34:14.320 --> 00:34:19.240
do my test pass, people are going to stop running them and they just become stale.

00:34:19.240 --> 00:34:19.640
All right.

00:34:34.940 --> 00:34:40.880
This episode is brought to you by SnapCI, the only hosted cloud-based continuous integration

00:34:40.880 --> 00:34:45.380
and delivery solution that offers multi-stage pipelines as a built-in feature.

00:34:45.380 --> 00:34:50.780
SnapCI is built to follow best practices like automated builds, testing before integration,

00:34:50.780 --> 00:34:53.880
and provides high visibility into who's doing what.

00:34:53.880 --> 00:34:59.120
Just connect Snap to your GitHub repo and it automatically builds the first pipeline for you.

00:34:59.120 --> 00:35:03.940
It's simple enough for those who are new to continuous integration, yet powerful enough to run

00:35:03.940 --> 00:35:05.400
dozens of parallel pipelines.

00:35:05.400 --> 00:35:07.720
More reliable and frequent releases.

00:35:07.720 --> 00:35:08.620
That's Snap.

00:35:08.620 --> 00:35:14.640
For a free, no obligation, 30-day trial, just go to snap.ci slash talkpython.

00:35:14.640 --> 00:35:27.940
Well, that's the other beef I've got with, with the, the, a lot of the unit test stuff

00:35:27.940 --> 00:35:29.320
with the testing and isolation.

00:35:29.540 --> 00:35:30.940
So I don't even get that.

00:35:30.940 --> 00:35:35.760
So if, if I want to, so one of the things is if test, the test suite is slow, you're not

00:35:35.760 --> 00:35:36.200
going to run it.

00:35:36.200 --> 00:35:36.820
So we've got it.

00:35:36.820 --> 00:35:38.560
We want to try to speed up test suites.

00:35:38.560 --> 00:35:44.320
But one of the ways to do that is to isolate every single function and every single test so

00:35:44.320 --> 00:35:46.680
that the test doesn't rely on it.

00:35:46.680 --> 00:35:48.700
This function doesn't rely on anything else.

00:35:49.100 --> 00:35:54.000
But then if I've got such isolated tests, why am I running the whole suite?

00:35:54.000 --> 00:35:58.100
Just run the thing, run the tests over the thing that I'm testing.

00:35:58.100 --> 00:35:58.580
Right.

00:35:58.580 --> 00:36:05.020
Because if you're not testing the integration, then you're doing like 95% rework that theoretically

00:36:05.020 --> 00:36:05.960
doesn't affect you, right?

00:36:05.960 --> 00:36:06.700
Right.

00:36:06.700 --> 00:36:12.640
If I'm writing code that, is modular and everything, if, like the stock example,

00:36:12.640 --> 00:36:18.540
um, if I want to check to see if the buy button works, I don't need to test to make sure that

00:36:18.540 --> 00:36:22.840
that functionality that I changed didn't break the printing function.

00:36:22.840 --> 00:36:23.240
Yeah.

00:36:23.240 --> 00:36:23.400
Yeah.

00:36:23.400 --> 00:36:26.940
The about page shouldn't fail when I change the trading engine, right?

00:36:26.940 --> 00:36:28.620
Yeah, exactly.

00:36:29.920 --> 00:36:34.840
So one thing that you talked about on, I think it was show eight, if I recall my,

00:36:34.840 --> 00:36:42.100
my ordering correctly, of your podcast was the theme was like writing software is like

00:36:42.100 --> 00:36:42.800
nothing else.

00:36:42.800 --> 00:36:49.680
And I found that really interesting and it really resonated with me, not necessarily on a testing

00:36:49.680 --> 00:36:53.400
level, but on a software engineering level, right?

00:36:53.400 --> 00:36:59.760
Like people say people typically who are not skilled in the art of writing software will

00:36:59.760 --> 00:37:04.140
come and say, Hey, look, your title is software engineer.

00:37:04.140 --> 00:37:06.320
We have other types of engineers.

00:37:06.320 --> 00:37:07.760
They build like bridges.

00:37:07.760 --> 00:37:17.120
They can tell us within 10% accuracy of not just the cost of the project, but the duration

00:37:17.120 --> 00:37:19.340
of the project and how many people need to be on it.

00:37:19.340 --> 00:37:21.380
Why can't you do that with software?

00:37:21.380 --> 00:37:24.820
And I think your, your sort of a riff on software is like nothing else.

00:37:24.820 --> 00:37:26.900
It was really, I think it was neat.

00:37:26.900 --> 00:37:29.680
Well, I appreciate that.

00:37:29.680 --> 00:37:30.800
I like that as well.

00:37:30.800 --> 00:37:36.940
The, that notion that it's like engineering or it's like architecture or it's like,

00:37:36.940 --> 00:37:40.780
you know, whatever it isn't, it's, it's, it's its own thing.

00:37:40.780 --> 00:37:43.340
It's hard to define what, what it's like.

00:37:43.340 --> 00:37:46.940
And now as I'm in a management role, I've got to do some of those things.

00:37:46.940 --> 00:37:51.740
I've got to come up with estimates and I'm, I'm often the evil guy that says, well, how long

00:37:51.740 --> 00:37:52.480
is this going to take?

00:37:52.480 --> 00:37:53.580
Are you going to be done next week?

00:37:53.620 --> 00:37:59.960
and, and I know the answer is nobody knows, but, but you know, you've got to ask

00:37:59.960 --> 00:38:00.880
those questions anyway.

00:38:00.880 --> 00:38:01.220
So.

00:38:01.220 --> 00:38:01.780
Yeah.

00:38:01.780 --> 00:38:04.920
I read a book by somebody and I totally forgot all the details.

00:38:04.920 --> 00:38:06.960
So I think it's lost.

00:38:06.960 --> 00:38:14.380
It was talking about this and it said, you know, people often refer to software engineering

00:38:14.380 --> 00:38:17.580
and I'd actually personally don't really like the term software engineer much.

00:38:17.580 --> 00:38:21.820
I call myself a software developer because I think it's, I don't want to put it too near

00:38:21.820 --> 00:38:24.360
architecture or engineering in people's mind.

00:38:24.360 --> 00:38:28.940
But it was saying, you know, one of the fundamental differences between like a civil engineer that

00:38:28.940 --> 00:38:36.220
builds a bridge and somebody that builds a soft piece of rich and interesting software is that

00:38:36.220 --> 00:38:39.880
you have to build the bridge over and over and over.

00:38:39.880 --> 00:38:44.640
If I'm going to build a bridge across this river, I'm going to build it here.

00:38:44.940 --> 00:38:46.680
And then, oh, we need another bridge.

00:38:46.680 --> 00:38:51.520
It's about like that bridge, but it goes across this river and it's just this much wider.

00:38:51.520 --> 00:38:52.140
Right.

00:38:52.140 --> 00:38:56.400
And so you can't, if this was software, you would just like take the bridge and change a

00:38:56.400 --> 00:38:57.760
setting and move it over.

00:38:57.760 --> 00:39:00.040
Like you would make a copy of it, but you can't copy bridges.

00:39:00.040 --> 00:39:02.720
So you rebuild them over and over and over.

00:39:02.720 --> 00:39:09.440
And in software, if a thing already exists, you just use it and you copy it and you incorporate

00:39:09.440 --> 00:39:10.060
as a library.

00:39:10.060 --> 00:39:14.260
If you're writing something often, I mean, I know there's a lot of wasteful reuse and what

00:39:14.260 --> 00:39:16.960
are a re rewriting, you know, not made here.

00:39:16.960 --> 00:39:18.140
So we're going to do it ourselves.

00:39:18.140 --> 00:39:24.000
But generally in software, if you're writing software, it's because it doesn't exist.

00:39:24.000 --> 00:39:25.080
It hasn't been done before.

00:39:25.080 --> 00:39:27.380
And that really gave me a different perspective.

00:39:27.380 --> 00:39:28.580
What do you think about that?

00:39:28.580 --> 00:39:29.680
Yeah.

00:39:29.680 --> 00:39:34.940
Well, there's a lot of not admitted here that I run into as well.

00:39:35.780 --> 00:39:41.520
And it also, there's, it takes a certain kind of person that's willing to dig through libraries

00:39:41.520 --> 00:39:43.940
and see if it applies to your problem right now.

00:39:43.940 --> 00:39:53.740
But yeah, the thing that I think software is most like actually is probably writing, like

00:39:53.740 --> 00:39:56.400
technical writing or just any kind of creative writing.

00:39:56.660 --> 00:40:04.020
Because like in, in, in literature and lots of forms of writing, we often talk about the

00:40:04.020 --> 00:40:06.620
first draft is, I mean, we talk about it as a draft.

00:40:06.620 --> 00:40:11.540
You have a first draft and that's not even usually the first thing.

00:40:11.540 --> 00:40:15.700
Usually you start with notes and then you go to a first draft and then, you know, you have

00:40:15.700 --> 00:40:19.020
many drafts before you have something that's ready for somebody else to read.

00:40:19.480 --> 00:40:24.520
That's probably closer to software because we, in the iterative approach, you, you, except

00:40:24.520 --> 00:40:30.060
for there's a lot of software engineers or software developers that, that think they're like awesome

00:40:30.060 --> 00:40:32.940
and that their code is perfect all the time.

00:40:32.940 --> 00:40:34.720
And that's just ridiculous.

00:40:34.720 --> 00:40:38.540
You need to let go of stuff and be willing to throw stuff away and redo it.

00:40:38.540 --> 00:40:38.980
Yeah.

00:40:38.980 --> 00:40:42.680
Throwing away code that you've worked on is hard to do.

00:40:42.680 --> 00:40:44.440
It's fun though.

00:40:44.440 --> 00:40:45.440
You should do it more often.

00:40:46.000 --> 00:40:51.140
And that's why I like, I like to, I like to put tests around the things that I'm not

00:40:51.140 --> 00:40:52.080
willing to throw away.

00:40:52.080 --> 00:40:54.400
And those are the interfaces that I have promises to.

00:40:54.400 --> 00:41:00.680
So that's, that's really where I like to, the creative freedom of software to be able to,

00:41:00.680 --> 00:41:06.260
to take an entire chunk of code, even if, you know, even a week before ship date and say,

00:41:06.260 --> 00:41:08.240
no, this stuff's just rotten.

00:41:08.240 --> 00:41:09.640
We need to just rewrite it.

00:41:09.640 --> 00:41:14.240
Instead of trying to figure out what it does, let's just re, re implement it.

00:41:14.780 --> 00:41:21.980
Certainly I've spent hours trying to figure out what a piece of software does and then

00:41:21.980 --> 00:41:26.340
more time trying to understand, well, can it be adapted to this situation?

00:41:26.340 --> 00:41:28.540
And is it sufficiently generalized?

00:41:28.540 --> 00:41:33.060
And, you know, we're not even talking about like, is it thread safe?

00:41:33.060 --> 00:41:36.180
And all these other like weird edge cases you might have to care about.

00:41:36.180 --> 00:41:36.460
Right.

00:41:37.140 --> 00:41:40.620
By the time you're done with that exercise, it was probably like two hours to write that

00:41:40.620 --> 00:41:42.020
functionality from scratch, right?

00:41:42.020 --> 00:41:42.840
Yeah.

00:41:42.840 --> 00:41:44.860
Possibly, you know, I mean, not always, but possibly.

00:41:45.420 --> 00:41:57.500
And then other things where I've like, I've spent a week writing something, but, but I think of, I like to try to think of the first time writing a piece of software as learning about what the problem is.

00:41:57.980 --> 00:42:00.520
And so you don't have to relearn the problem.

00:42:00.520 --> 00:42:01.480
You've already know it.

00:42:01.480 --> 00:42:07.180
So if you even like deleted all the files and started over, it would take you a day for the second time.

00:42:07.180 --> 00:42:09.220
And then the third time, maybe an hour.

00:42:09.220 --> 00:42:11.880
Just don't be afraid to throw things away.

00:42:11.880 --> 00:42:21.300
That's interesting because you think I spent a week working on this, but it's understanding the problem, like you say, and like thinking through the trade-offs.

00:42:21.300 --> 00:42:26.360
And, and a lot of that probably gets better with time as you understand it better, not worse.

00:42:26.360 --> 00:42:31.280
Now, the place where people really want to throw a code away is other people's code.

00:42:31.280 --> 00:42:34.400
And that's where I think people should like hold off a little bit.

00:42:34.560 --> 00:42:43.080
And like the Michael Feathers book that you brought up, around that timeframe, there was a lot of talk about what to do with all this horrible legacy code.

00:42:43.080 --> 00:42:48.080
And, and I never think of legacy code as a bad word.

00:42:48.080 --> 00:42:50.280
It was a bad word for a while.

00:42:50.280 --> 00:42:55.460
I don't know if it still is, but I think of legacy code as the stuff that's paying my salary.

00:42:55.460 --> 00:42:58.040
So I really like legacy code.

00:42:58.040 --> 00:43:00.280
so I treat it like that.

00:43:00.280 --> 00:43:02.780
I treat it as the thing that's giving me money right now.

00:43:03.440 --> 00:43:08.780
Legacy code that's still being used by definition was something that was super valuable and useful.

00:43:08.780 --> 00:43:09.100
Right.

00:43:09.100 --> 00:43:18.900
Or I guess somebody left some old website running, but generally speaking, it's, if it was not useful, it would have been turned off or somehow outdated.

00:43:18.900 --> 00:43:19.180
Right.

00:43:19.180 --> 00:43:19.860
Yeah.

00:43:19.860 --> 00:43:25.300
Well, I mean, in, we're, we're, I'm thinking more along the lines of the, the, my job right now.

00:43:25.420 --> 00:43:31.920
we've got, I mean, a, a test instrument's got thousands of lines of code and the, it goes back.

00:43:31.920 --> 00:43:40.840
Like I started on the code base that I'm working on now, maybe five years ago, but, it had 10 years of history before I got there.

00:43:40.840 --> 00:43:49.020
So this code is, old, even if the people are still around that made the decisions, they, they don't remember why they made certain decisions.

00:43:49.020 --> 00:44:01.180
So if there's some weird switch case statement, you got to try to find out, well, that's one of the hard parts is trying to find out is this, was this intent, an intentional decision or just a whim of a developer?

00:44:01.180 --> 00:44:04.860
How many different, types of version control has it gone through?

00:44:04.860 --> 00:44:07.240
Like, was it CVS in the beginning or something like this?

00:44:07.240 --> 00:44:08.900
Or is it still on the same one?

00:44:09.460 --> 00:44:11.600
I'm not, I think it did switch.

00:44:11.600 --> 00:44:20.420
I'm not sure what it was initially because there were, there are some like, the time where they would put like the version string and the header of the file.

00:44:20.420 --> 00:44:23.000
Those are still around, but they're not filled out anymore.

00:44:23.000 --> 00:44:30.900
right now we're, we're actually using clear case, which, I'm not real thrilled about, but it's not terrible.

00:44:31.580 --> 00:44:44.680
One of the things that you have going on at python testing.net is you have a book that sort of compares the three major frameworks that people might use to, you know, they're, they're called unit testing frameworks.

00:44:44.680 --> 00:44:52.380
But like you sort of point out, you can choose the level of aggregation or isolation you want to get into to sort of run the spectrum, right?

00:44:52.380 --> 00:44:52.940
Yeah.

00:44:52.940 --> 00:44:53.340
Yeah.

00:44:53.340 --> 00:44:54.200
Thanks for bringing that up.

00:44:54.200 --> 00:44:54.480
Yeah.

00:44:54.480 --> 00:44:55.280
What's the story with your book?

00:44:55.280 --> 00:44:57.340
I was around like 2010.

00:44:58.140 --> 00:45:01.980
I found myself without a test framework and I looked at those three.

00:45:01.980 --> 00:45:06.140
I looked at unit test, nose and pie test, and I had trouble.

00:45:06.140 --> 00:45:14.400
I looked at him like what I mean is I searched on the web and tried to read things about him, but I couldn't tell whether they were going to be useful for my job or not.

00:45:14.400 --> 00:45:15.940
And I needed something right away.

00:45:15.940 --> 00:45:28.040
So I wrote my own, but, and while I'm, while I was maintaining my own, test executive, for work, I started researching these and I wanted to,

00:45:28.040 --> 00:45:34.200
try to try to play with them and create something so that nobody else had to go through what I did.

00:45:34.200 --> 00:45:38.980
If trying to track down what's, what's true information and what's old and what's new.

00:45:38.980 --> 00:45:53.440
So I went through like, a simple math problem and, and a little, string conversion problem and, used, those three frameworks, on those, this, on the same problem.

00:45:53.440 --> 00:46:07.480
So people can see apples to apples, compare the three frameworks and, and then extended just, you know, the basics of getting, getting a test running, through to how fixtures work.

00:46:07.480 --> 00:46:11.860
And it's really the mechanics of the mechanics and syntax of test writing.

00:46:11.860 --> 00:46:28.640
And I, I've, I've written other about other things, but the book is, basically a collection of those, mechanics posts so that people can come up to the speed really quickly on, on any of those frameworks and compare them as well.

00:46:28.640 --> 00:46:29.840
Yeah.

00:46:29.840 --> 00:46:34.040
That sounds really helpful if you're, you're getting started and you're not really sure what to start with.

00:46:34.040 --> 00:46:35.760
So do you pick a winner in the book?

00:46:36.880 --> 00:46:47.080
you know, I didn't in the book, but I think, I think pytest is a clear winner for me because of the fixture mechanism that's built in.

00:46:47.080 --> 00:46:48.640
Plus it's a superset.

00:46:48.640 --> 00:46:51.820
pytest really does everything that the others do and more.

00:46:51.820 --> 00:47:00.560
There's definitely applications that I, and I, when I got into it, I expected to, to pick one and like, not like the others.

00:47:00.780 --> 00:47:01.800
I'm not there yet.

00:47:01.800 --> 00:47:03.840
I think all, all three of those are reasonable.

00:47:03.840 --> 00:47:08.580
the most reasonable is, probably unit test and pytest.

00:47:08.580 --> 00:47:09.340
Those are the two.

00:47:09.340 --> 00:47:09.940
Yeah.

00:47:09.940 --> 00:47:12.620
Unit test is probably the most, what, like straightforward.

00:47:13.840 --> 00:47:15.600
I, I don't think it's straightforward.

00:47:15.600 --> 00:47:26.920
I think it's, I think it's the most confusing to start with, because it's, it's this X unit style that came from Java that you have to derive from a, you have to derive from a test case class.

00:47:27.480 --> 00:47:32.160
And also you can't, I mean, they discourage you from using straight asserts.

00:47:32.160 --> 00:47:34.720
You should use these assert helper functions.

00:47:34.720 --> 00:47:38.360
And, you know, I think there's more to memorize.

00:47:38.360 --> 00:47:41.400
If you, if you're just starting out, pytest is a lot easier.

00:47:41.400 --> 00:47:52.800
And there, there, I don't, I don't think any, anybody new to this should use nose, because it's not really supported by a very, I don't even know if it is supported anymore.

00:47:53.040 --> 00:47:56.420
There, there has been a little bit of effort on it, but not much.

00:47:56.420 --> 00:48:02.620
but there's, I included writing about it because there is, there's quite a few people that still use it.

00:48:02.620 --> 00:48:11.180
And if, if you're not, if it's not your decision and it's your job to use it, then I want to, I want to have a reference for people to be able to come up to speed quick.

00:48:11.180 --> 00:48:14.820
I think I'm going to, I would like to write a follow-up book.

00:48:14.820 --> 00:48:22.540
So the book I have now, it's just a, like I said, it's a $5 collection of, of all of the, of a whole bunch of posts.

00:48:22.540 --> 00:48:27.000
but I'm, I'm, I'm, I write, I read a lot on a Kindle.

00:48:27.000 --> 00:48:34.500
So I wanted to make sure that those sorts of posts were available on, for somebody to be able to read on a, a e-reader or something.

00:48:34.500 --> 00:48:35.480
Yeah, nice.

00:48:35.480 --> 00:48:38.920
And I'll be sure to put a link to the book and whatnot in the show notes.

00:48:38.920 --> 00:48:50.180
But I do want to write a follow-up that, instead of just a collection of posts is actually in a, in a kind of a technical book format, and walks through stuff and doesn't repeat things too much.

00:48:50.180 --> 00:48:54.180
and I don't, I don't know if I'm going to include no's.

00:48:54.180 --> 00:48:59.280
I, I think that, I think it would be sufficient to just include unit test and pi test in the discussion.

00:48:59.280 --> 00:48:59.720
Yeah.

00:48:59.720 --> 00:49:00.000
Okay.

00:49:00.000 --> 00:49:10.500
So, you know, six years ago, maybe the space looked differently and now you're like, all right, pi test is kind of the clear winner in some ways.

00:49:10.500 --> 00:49:14.120
And then, well, unit test is a built in, so people are choosing it because it's built in.

00:49:15.240 --> 00:49:24.660
I mean, it's also, I mean, for a lot of like algorithmic things, like in the things I do that are heavy on fixture use, pi test is a clear winner.

00:49:24.660 --> 00:49:36.840
If it's, if you've got a whole bunch of tight algorithms and you're in test speed really is a, the overhead of the overhead of pi test isn't very much, but the overhead of unit test is less.

00:49:36.840 --> 00:49:44.960
So if, if test speed really is a, if you're trying to catch every millisecond out of your test suite, unit tests will be a little faster.

00:49:44.960 --> 00:49:45.680
Right.

00:49:45.680 --> 00:49:46.000
Okay.

00:49:46.000 --> 00:49:46.600
Good to know.

00:49:46.600 --> 00:49:50.600
I'll probably get a bunch of hate mail from the pi test people, after, after this, but.

00:49:50.600 --> 00:49:51.300
Oh yeah.

00:49:51.300 --> 00:49:57.100
I think we've set ourselves up to receive a lot of, feedback on various areas, but.

00:49:57.100 --> 00:50:06.920
There's a lot of respect between the people that are developing unit tests and the people that are developing, developing pi tests because they're, they're, they're, it's, there's two ways to solve the same problem.

00:50:06.920 --> 00:50:09.680
And, they're learning from each other.

00:50:09.680 --> 00:50:12.860
And, and I think having both around is a very good thing.

00:50:12.860 --> 00:50:13.660
Yeah.

00:50:13.660 --> 00:50:14.220
Yeah, absolutely.

00:50:14.220 --> 00:50:15.780
All right.

00:50:15.780 --> 00:50:18.540
A few more things I want to talk to you before, before I let you go.

00:50:18.540 --> 00:50:20.700
Tell us a little bit about your podcast.

00:50:20.700 --> 00:50:23.440
It, it was kind of a follow onto the book, right?

00:50:23.440 --> 00:50:27.080
You wrote the book and you've got the website that's, that's doing a lot of good.

00:50:27.080 --> 00:50:33.660
And you're like, you know, let's, let's make this more, more of a weekly, semi weekly sort of conversation with the world.

00:50:33.660 --> 00:50:33.880
Right.

00:50:33.880 --> 00:50:34.840
Right.

00:50:34.840 --> 00:50:43.840
So the intent was actually to start off weekly and get more than a weekly, like maybe a couple a week, but, it's, I'm really trying to do one a week, but it's, I'm really trying to do one a week.

00:50:43.840 --> 00:50:45.500
But it's often once a month.

00:50:46.100 --> 00:50:52.540
The, I want to cover more topics that I can, then I can write blog posts about.

00:50:52.620 --> 00:50:57.380
And so that's the real, the real reason why I'm doing the podcast is to try to cover more topics.

00:50:57.380 --> 00:51:02.680
And also, things that I think somebody wouldn't necessarily read about.

00:51:02.680 --> 00:51:09.240
Like, I did an episode on the waterfall model that I think, you know, it'd probably be an interesting thing to listen to.

00:51:09.300 --> 00:51:15.340
But you know, pump somebody's probably not going to go read about the history of the waterfall model.

00:51:15.340 --> 00:51:21.420
So I've noticed that a lot of my, my audience is coming from developers and from testers.

00:51:21.960 --> 00:51:30.140
And I know that from my own experience as a developer that there might, there's huge gaps in my education where it comes to testing.

00:51:30.140 --> 00:51:31.860
So a developer usually gets a test.

00:51:31.860 --> 00:51:36.240
the introduction to testing is to talk about test driven development.

00:51:36.620 --> 00:51:47.400
And the, writing a test part, we, we get a statement that says first write a failing test, but no information on how to do that or what the test should look like.

00:51:47.400 --> 00:52:00.900
And, and then, on the other end, you've got testers that come, you know, maybe come from a different kind of background and they don't have a lot of the skills and education that developers had, but they're expected to write automated tests.

00:52:00.900 --> 00:52:09.560
Now I really want to, on both sides, I want to fill the education gaps in both testers and developers to, to fill all those gaps in.

00:52:09.560 --> 00:52:11.280
And I know that people are busy.

00:52:11.280 --> 00:52:12.660
They've already got a ton of stuff to do.

00:52:12.660 --> 00:52:15.200
So I thought an audio format would be a good way to do that.

00:52:15.200 --> 00:52:18.920
So people can, you know, get a little bit on their way to work or whatever.

00:52:18.920 --> 00:52:19.880
Yeah.

00:52:19.880 --> 00:52:25.360
And it's definitely a different type of interaction than a blog or, or a book, right?

00:52:25.360 --> 00:52:28.100
Even than it, even different than an audio book.

00:52:28.440 --> 00:52:34.240
You know, you can just fire up your podcasts while you're driving, biking, walking, doing the dishes, whatever.

00:52:34.240 --> 00:52:35.780
I really liked that format.

00:52:35.780 --> 00:52:38.320
So obviously I guess I'm spending a lot of time on it, right?

00:52:38.320 --> 00:52:39.280
Yeah.

00:52:39.280 --> 00:52:43.520
And I also, I was finding that I wasn't writing as much as I wanted to.

00:52:43.520 --> 00:52:49.780
And I thought maybe I could, and I have a less time now as I go into a manager role.

00:52:49.780 --> 00:52:53.740
And I thought maybe it'd be easier to do a podcast than it would be to write.

00:52:53.740 --> 00:52:56.900
But I've found out that it actually takes more time than writing.

00:52:57.020 --> 00:52:59.460
It's a lot of work, but it's, it's also a lot of fun, right?

00:52:59.460 --> 00:53:00.440
To hear back from everybody.

00:53:00.440 --> 00:53:01.740
So I just love it.

00:53:01.740 --> 00:53:07.100
And, one of the things I was worried about that my, so I'm, since I'm not a web developer,

00:53:07.100 --> 00:53:12.640
I thought that a lot of the audience is from web development community, but the, I thought

00:53:12.640 --> 00:53:14.200
maybe that would be a hindrance.

00:53:14.200 --> 00:53:19.480
But when I was talking to Harry, I think there's a lot of similarities to how, how web systems

00:53:19.480 --> 00:53:22.520
go together and, and complex embedded systems.

00:53:22.520 --> 00:53:24.500
So I think, I think it all works out.

00:53:24.500 --> 00:53:26.040
Yeah, I would say so.

00:53:26.040 --> 00:53:29.460
And I think the diversity of viewpoints, it's super helpful.

00:53:29.460 --> 00:53:31.660
Like not everybody's writing straight up web apps.

00:53:31.660 --> 00:53:36.440
So plus I've heard, heard from a lot of people, that I would have, would never have heard

00:53:36.440 --> 00:53:37.300
from otherwise.

00:53:37.300 --> 00:53:38.080
Yeah.

00:53:38.080 --> 00:53:38.360
Yeah.

00:53:38.360 --> 00:53:39.320
That's, that's really cool.

00:53:39.320 --> 00:53:41.980
So I'm really glad to see it going well for you.

00:53:41.980 --> 00:53:42.520
That's awesome.

00:53:42.520 --> 00:53:44.620
I know we spoke just a little bit before you guys started.

00:53:44.620 --> 00:53:45.300
So that's cool.

00:53:45.300 --> 00:53:46.580
Good to, good to see it going.

00:53:46.800 --> 00:53:52.260
And speaking of that, we are both from Portland and something awesome is happening in Portland

00:53:52.260 --> 00:53:53.440
in June, right?

00:53:53.440 --> 00:53:54.640
Yeah.

00:53:54.640 --> 00:53:55.560
PyCon is here.

00:53:55.560 --> 00:53:55.980
Yay.

00:53:55.980 --> 00:53:56.520
Yay.

00:53:56.520 --> 00:53:58.000
PyCon comes to our hometown.

00:53:58.000 --> 00:54:02.480
I happen to be living in Germany for a year, so I'm flying like 12 hours to get there, but

00:54:02.480 --> 00:54:04.700
nonetheless, I'm still going to go.

00:54:04.700 --> 00:54:05.480
It's going to be awesome.

00:54:05.480 --> 00:54:06.400
Are you going?

00:54:06.400 --> 00:54:07.380
Yeah, definitely.

00:54:08.240 --> 00:54:15.100
and I put, actually I've, I've submitted, four proposals, three talks and one

00:54:15.100 --> 00:54:15.660
tutorial.

00:54:15.660 --> 00:54:18.020
I don't know if I'll get any, but we'll see.

00:54:18.020 --> 00:54:19.280
Oh, very nice.

00:54:19.280 --> 00:54:19.800
That's awesome.

00:54:19.800 --> 00:54:21.720
So hopefully, hopefully they do get accepted.

00:54:21.720 --> 00:54:22.220
That'd be great.

00:54:22.220 --> 00:54:23.420
Yeah.

00:54:23.420 --> 00:54:27.500
So if people are going, I'm sure a lot of listeners are going to go, feel free to reach

00:54:27.500 --> 00:54:31.980
out to me and I'm sure Brian, you'd be interested in meeting people that want to chat as well.

00:54:31.980 --> 00:54:32.220
So.

00:54:32.220 --> 00:54:32.840
Yeah.

00:54:32.840 --> 00:54:36.380
What, one of the things we talked about is giving away some copies of my book.

00:54:36.380 --> 00:54:36.840
Yeah.

00:54:36.840 --> 00:54:42.820
So if you go to talk python.fm and at the top, it says friends, the show, long as you

00:54:42.820 --> 00:54:45.380
are subscribed on that list, all it takes is an email address.

00:54:45.380 --> 00:54:50.360
We will, I will, I suppose only one of us will do this randomly choose.

00:54:50.360 --> 00:54:50.920
What do you say?

00:54:50.920 --> 00:54:52.040
Five copies.

00:54:52.040 --> 00:54:52.300
Yeah.

00:54:52.300 --> 00:54:53.240
Let's give away five.

00:54:53.240 --> 00:54:53.620
Awesome.

00:54:53.620 --> 00:54:59.940
So on the week that this show comes out, I will randomly choose five listeners from the

00:54:59.940 --> 00:55:05.860
friends of the show and we will be shipping you eBooks of Brian's testing Python testing

00:55:05.860 --> 00:55:06.100
book.

00:55:06.100 --> 00:55:06.740
Yeah.

00:55:06.740 --> 00:55:09.980
Unfortunately, it's got a really long title that I don't even remember.

00:55:09.980 --> 00:55:15.240
We'll ship you the book about testing with a really long title.

00:55:15.240 --> 00:55:15.980
No, no, it's good.

00:55:15.980 --> 00:55:18.280
We'll definitely send you an eBook copy.

00:55:18.280 --> 00:55:20.560
So sign up and you'll be in the running.

00:55:20.560 --> 00:55:21.480
Thanks for doing that, Brian.

00:55:21.480 --> 00:55:21.880
That's awesome.

00:55:21.880 --> 00:55:23.260
All right.

00:55:23.260 --> 00:55:24.560
Parting thoughts.

00:55:24.560 --> 00:55:27.400
I always ask my guests, well, unless we run out of time.

00:55:28.000 --> 00:55:30.700
If you're going to write some Python code, what editor do you use?

00:55:30.700 --> 00:55:35.060
I use Sublime, but I use it for everything, not just Python code.

00:55:35.060 --> 00:55:36.060
Sublime is good.

00:55:36.060 --> 00:55:36.960
Very nice.

00:55:36.960 --> 00:55:37.260
Very nice.

00:55:37.260 --> 00:55:38.520
And PyPI packages.

00:55:38.520 --> 00:55:41.280
What one's your favorite or people maybe don't know about they should?

00:55:41.280 --> 00:55:46.660
Well, this is probably nobody's going to care about this, but my favorite is PyVisa because

00:55:46.660 --> 00:55:48.680
I couldn't do my job without PyVisa.

00:55:49.180 --> 00:55:49.840
Nice, nice.

00:55:49.840 --> 00:55:50.040
Yeah.

00:55:50.040 --> 00:55:52.360
So PyVisa for talking to the machines.

00:55:52.360 --> 00:55:53.260
That's cool.

00:55:53.260 --> 00:55:56.820
And then maybe I'll throw in pytest as well, right?

00:55:56.820 --> 00:55:57.640
Because that's not built in.

00:55:57.640 --> 00:55:58.580
Oh, right.

00:55:58.580 --> 00:55:58.960
Yeah.

00:55:58.960 --> 00:56:00.340
I guess I should have brought that up.

00:56:00.340 --> 00:56:01.440
Perhaps.

00:56:01.440 --> 00:56:02.280
No, no.

00:56:02.280 --> 00:56:02.660
It's all good.

00:56:02.660 --> 00:56:03.320
They all go together.

00:56:03.320 --> 00:56:09.720
One of the things, because it's not a package, but I'd like to do a shout out to the Anaconda

00:56:09.720 --> 00:56:16.280
team or whoever does that because that's the distribution that I encourage people at work to use.

00:56:16.280 --> 00:56:17.820
They're doing really amazing stuff.

00:56:17.820 --> 00:56:18.040
Yeah.

00:56:18.040 --> 00:56:19.080
That's Travis Oliphant.

00:56:19.080 --> 00:56:25.340
And the Continuum guys, they were on show 34 and they definitely make Python in general

00:56:25.340 --> 00:56:26.900
more accessible, especially on Windows.

00:56:26.900 --> 00:56:27.720
So very cool.

00:56:27.720 --> 00:56:28.520
Yeah.

00:56:28.520 --> 00:56:32.520
It's actually that show that got me to download the Anaconda package and try it out.

00:56:32.520 --> 00:56:33.620
Oh, nice.

00:56:33.620 --> 00:56:34.040
Very cool.

00:56:34.040 --> 00:56:36.660
So final call to action before we say goodbye.

00:56:36.660 --> 00:56:38.120
Subscribe to your podcast.

00:56:38.120 --> 00:56:38.900
How do they do it?

00:56:38.900 --> 00:56:40.000
Oh, yeah.

00:56:40.000 --> 00:56:47.580
On the pythontesting.net slash podcast, there's a bunch of information there.

00:56:48.020 --> 00:56:51.540
And I've also got a, I send people information.

00:56:51.540 --> 00:56:55.940
I've got a little email newsletter that goes out whenever I post anything new.

00:56:56.400 --> 00:57:02.160
You can reach me on Twitter @brianokken or the podcast is at test podcast.

00:57:02.660 --> 00:57:03.020
Awesome.

00:57:03.020 --> 00:57:03.060
Awesome.

00:57:03.060 --> 00:57:04.420
And all that's going in the show notes.

00:57:04.420 --> 00:57:10.020
Brian, this has been really fun and it's interesting to get different opinions on testing.

00:57:10.020 --> 00:57:11.840
So thanks so much for sharing yours.

00:57:11.840 --> 00:57:12.700
Oh, yeah.

00:57:12.700 --> 00:57:13.720
Thanks a lot for having me on.

00:57:13.720 --> 00:57:14.520
You bet.

00:57:14.520 --> 00:57:14.960
Talk to you later.

00:57:16.320 --> 00:57:18.760
This has been another episode of Talk Python To Me.

00:57:18.760 --> 00:57:20.160
Today's guest was Brian Okken.

00:57:20.160 --> 00:57:22.860
And this episode has been sponsored by Hired and SnapCI.

00:57:22.860 --> 00:57:24.920
Thank you guys for supporting the show.

00:57:24.920 --> 00:57:27.260
Hired wants to help you find your next big thing.

00:57:27.260 --> 00:57:32.900
Visit Hired.com slash Talk Python To Me to get five or more offers with salary and equity presented right up front.

00:57:33.140 --> 00:57:35.720
And a special listener signing bonus of $2,000.

00:57:35.720 --> 00:57:39.500
SnapCI is modern, continuous integration and delivery.

00:57:39.500 --> 00:57:42.500
Build, test, and deploy your code directly from GitHub.

00:57:42.500 --> 00:57:46.420
All in your browser with debugging, Docker, and parallelism included.

00:57:46.420 --> 00:57:49.520
Try them for free at snap.ci slash Talk Python.

00:57:49.520 --> 00:57:55.880
You can find the links from today's show at talkpython.fm/episodes slash show slash 45.

00:57:55.880 --> 00:57:57.880
And be sure to subscribe.

00:57:57.880 --> 00:58:00.460
Open your favorite podcatcher and search for Python.

00:58:00.460 --> 00:58:01.540
We should be right at the top.

00:58:01.920 --> 00:58:05.740
You can also find the iTunes and direct RSS feeds in the footer of the website.

00:58:05.740 --> 00:58:10.740
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.

00:58:10.740 --> 00:58:13.920
You can hear the entire song on talkpython.fm.

00:58:13.920 --> 00:58:18.900
And don't forget to check out the new podcast t-shirt at talkpython.fm/shirt

00:58:18.900 --> 00:58:21.440
and share your love for Python with the whole world.

00:58:21.440 --> 00:58:23.520
This is your host, Michael Kennedy.

00:58:23.520 --> 00:58:24.560
Thanks for listening.

00:58:24.560 --> 00:58:26.480
Smix, take us out of here.

00:58:30.700 --> 00:58:31.680
Haven't been sleeping.

00:58:31.680 --> 00:58:32.000
Haven't been sleeping.

00:58:32.000 --> 00:58:33.600
I've been using lots of rest.

00:58:33.600 --> 00:58:36.480
I'll pass the mic back to who rocked it best.

00:58:36.480 --> 00:58:38.060
I'm first developers.

00:58:38.060 --> 00:58:40.060
I'm first developers.

00:58:40.060 --> 00:58:41.160
I'm first developers.

00:58:41.160 --> 00:58:44.160
I'm first developers.

00:58:44.160 --> 00:58:45.160
I'm first developers.

00:58:45.160 --> 00:58:47.160
I'm first developers.

00:58:47.160 --> 00:58:48.780
First of all, first of all, first of all, first of all.