Panel Discussion: Testing

Typescript is a free, free-to-use JavaScript service for web developers. It is open-source, free-of-charge, and free of any unfavorable use cases. It's free to use any language you want. Everything you need. It's free to use.

Any questions? I would like to welcome Tomas Lakomi, Kensi Dotts, Iris Schaffer, and Sophie Au to our panel. Are they all here? Hello! Hello! Excellent. Hi. How are you all doing? Not too bad, not too bad. Awesome. Sweet. That's fantastic.

So I feel like a little bit, coming back to the Among Us thing that was brought up earlier, I feel like a little bit of the imposter in here. Because I do write tests in the projects that I control, but I also worked in many different agencies and companies and projects where testing was met with skepticism, let's put it that way. So I'm really excited to hear your opinions and ideas on this topic. Because I think I was not the only one struggling with this inner tension of knowing that tests provide a big value. But then also seeing bad practices and seeing problems.

So would you all very quickly introduce yourselves and what you think is the number one value from testing? Let's start with Iris. Ok I'll start then. So my name is Iris, I work at Spotify in Stockholm in Sweden. And I think for me, the number one benefit would be the quality for the end user. Just ensuring that on every release. Without having to manually test every time, every feature. Oh yeah, been there, done that, got a t-shirt. What's your take on this, Sophie? Hey everyone, I'm Sophie. I'm a full stack front-end-T developer at Donut in Berlin. And for me, I think the main thing about testing similar to Iris is knowing that the stuff I'm pushing to production works. Especially because we do mobile apps, so it's not like you can just push a quick fix, but you actually have to do a new release. So actually being confident that the app we're shipping to the user works and we don't have to push 20 bug releases quick after. That sounds convincing.

I would like to welcome Tomasz Lakomi, Kenzi Dotz, Iris Schaffer, and Sophie Au to our panel. Are they all here? Hello! Hello! Ah, excellent! So good to see you all! Hi! How are you all doing? Yeah, not too bad. Awesome, sweet, that's fantastic. So, I feel like a little bit coming back to the Among Us thing that was brought up earlier. I feel like a little bit of the imposter in here, because I do write tests in the projects that I control, but I also worked in many different agencies and companies and projects where testing was met with skepticism, let's put it that way. So, I'm really excited to hear your opinions and ideas on this topic, because I think I was not the only one struggling with this like, inner tension of kind of knowing that tests provide a big value, but then also seeing like, bad practices and seeing problems.

Tomasz, how about you? Hey everyone, so my name is Tomasz Rokome, I am a senior front-end engineer at Olex Group and I also record videos for Egghead.io. And when it comes to the number one value of testing, apart from the things mentioned by both Iris and Sophie, I would like to say that testing makes me sleep better at night, because I push something to production, I don't have to worry for the entire evening that it is going to break. In fact, we've pushed something to production an hour ago and I am not checking Slack or notifications right now. I know that feeling and I know the other side of this.

Kent, how about you? I learned a bunch from your testing talks and workshops. Yeah, thank you. So, my name is Kent and I made testing-javascript.com, where I teach people everything that I know about testing. And I don't have a whole lot to add to what's been said. One thing is I got started with testing with my open-source libraries, because every time I wanted to push a release, I had to go through this. I brought up the library on a page and clicked around all over the place and it just took a lot of time for something I was doing for free. So I thought, I wonder if I could just clone myself and do that with my clones, so I can go on and move on. And that's what tests are for me. It's like a thousand little Kents going through all of these different things I always did. I see, interesting.

So I heard a bunch of really good reasons for why I want to test. But I know, bear with me, this has been a few years ago when I started. Actually not a few years ago, that has been a long time ago. But when I started with software testing, I basically had to read a really thick book, and it was not very fun. But if I am a react developer who's just starting, how do I get started with writing tests? What's a good path? Well, I'll go ahead and get started there. I think that something that's important to keep in mind with testing is that testing is not anything different from regular software development. So it's just another thing that you're writing software for. And so having an idea of what a fundamental test even is, is really useful. And basically, a test is software that will give you some sort of notification when things are not working as expected. And so yeah, like how do you get started? The answer to that question is the same generally as like, how do I learn Framework X or how do I build this feature or whatever. Because it's no different from any other software that you're going to write. Right. But I've seen lots of courses or literature that basically assumes you're starting on a Greenfield project. But I think for most people, that's not the case. Most people here watching right now probably have a huge code base and wonder, like, how do I even get started? Even if I know how to write tests, which a lot of the material out there covers, how do I know how to start in my existing code base? How do I get the biggest bang for my buck? How do I find out? Where do I start? I'm happy to take that one. So in my experience, like I'll assume it's like React, like web app end-to-end tests are usually kind of my first go-to, which essentially, you know, generally, even if you don't actually write tests yet, you have someone who's checking that the app works, right? I mean, worst case, it's the user when it's in production, but you have someone that's gonna like tell you, hey, like the checkout button is broken.

So, would you all very quickly introduce yourselves and what you think is like the number one value from testing? Let's start with Iris. Okay, I'll start then. So, my name is Iris, I work at Spotify in Stockholm in Sweden, and I think for me the number one benefit would be the quality for the end user, just ensuring that on every release without having to manually test every time, every feature. Oh yeah, been there, done that, got a t-shirt. What's your take on this Sophie? Hey everyone, I'm Sophie, I'm a full-stack front-end tea developer at Donut in Berlin, and for me, I think the main thing about testing similar to Iris is knowing that the stuff I'm actually pushing to production works, in my case especially, because we do a mobile app, so it's not like you can just push a quick fix, but you actually have to do a new release. So actually being confident in that the app we're shipping to the user works and we don't have to push 20-bug releases quick after, that's really good. Oh that sounds convincing. Tomas, how about you? Hey everyone, so my name is Tomasz Rakome, I am a senior front-end engineer at Olex Group, and I also record videos for Ekhel.io. And when it comes to the number one value of testing, apart from the things mentioned by both Iris and Sofi, I would like to say that testing makes me sleep better at night. Because I push something to production, I don't have to worry for the entire evening that it is going to break. In fact, we pushed something to production an hour ago, and I'm not checking slack or notifications right now. I know that feeling and I know the other side of this. Kent, how about you? I learned a bunch from your testing talks and workshops, so... Yeah, thank you. Yeah, so my name is Kent and I made TestingJavascript.com, where I teach people everything that I know about testing. And I don't have a whole lot to add to what's been said. One thing is, I got started with testing with my open source libraries, because every time I pushed or I wanted to push a release, I had to go through this. I brought up the library on a page and clicked around all over the place and it just took a lot of time for something I was doing for free. So I wondered if I could just clone myself and do that with my clones so I can go on and move on. That's what tests are for me. It's like a thousand little kents going through all of these different things I always did. I see. Interesting. So I heard a bunch of really good reasons for why I want to test. But I know, bear with me, this has been a few years ago when I started. Actually not a few years ago, that has been a long time ago. When I started with software testing, I basically had to read a really thick book and it was not very fun. But if I am a React developer who is just starting, how do I get started with writing tests? What's a good path? Well, I'll go ahead and get started there. So I think that something that's important to keep in mind with testing is that testing is not anything different from regular software development. So it's just another thing that you're writing software for.

And just writing end-to-end tests essentially kind of automates that check. So yeah, my general recommendation is kind of what's like the most crucial part of your app? Is it your checkout button? Is it, I don't know, like you're sending some financial data around, just write a single end-to-end test for the most important functionality of your app. And then from there, kind of branch out and try to cover it kind of as much as possible. And don't get too bogged down in like unit tests and like the 5,000 edge cases. Just make sure you have like a rough idea that covers like 80% of the functionality.

And so having an idea of what a fundamental test even is, is really useful. And basically a test is software that will give you some sort of notification when things are not working as expected. And so, yeah, like, how do you get started? It really, the answer to that question is the same generally as, like, how do I learn framework X or how do I, you know, build this feature or whatever. Because it's no different from any other software that you're going to write. Right. But I've seen lots of software out there, I'm sorry, courses or literature that basically assumes you're starting on a greenfield project. But I think for most people that's not the case. Most people here watching right now probably have a huge code base and wonder, like, how do I even get started? Even if I know how to write tests, which a lot of the material out there covers, how do I know how to start in my existing code base? How do I get the biggest bang for my buck? How do I find out? Where do I start?

I'm happy to take that one. So in my experience, I'll assume it's the React web app. End-to-end tests are usually my first go-to, which essentially generally, even if you don't actually write tests yet, you have someone who's checking that the app works. I mean, worst case, it's the user when it's in production, but you have someone that's going to tell you, hey, the checkout button's broken. And just writing end-to-end tests essentially kind of automates that check. My general recommendation is what's the most crucial part of your app? Is it your checkout button? I don't know, like you're sending some financial data around, just write a single end-to-end test for the most important functionality of your app. And then from there, branch out and try to cover as much as possible. And don't get too bogged down in unit tests and the 5,000 edge cases. Just make sure you have a rough idea that covers like 80% of the functionality.

That sounds good to me. And I know that I wanted to do that so many times when things broke in production and I was working with customer projects and you get calls to unholy hours to your project manager who then like tries to call you while you're trying to sleep. How can I convince? So now that I might be the person who's like, OK, I see the problem. I want to write tests. I learned how to write tests. And I now know where to start. How do I convince my team to, A, join the effort? And B, also, how do I convince my manager that I'm not slacking off and not spending time on something that's useful? I can take this one because I actually have a blog post around the same idea. So there's a couple of things around here. First up, you shouldn't have to convince your manager, your product manager or anyone, really. Because the same way I don't have to convince my manager that I would like to use useState or useEffect or any other hook from React, consider testing to be a part of the thing that I'm trying to deliver. In other words, I, as a software engineer, I am getting paid to not only build and ship software, but also ship software that actually works and brings value to our users. Ideally, I would love to get paid for shipping broken software, but this is not how the world works. But in a more realistic scenario, in which you have a legacy code base and nobody is writing any tests and you would like to create this test setup and pave the way for future generations who are going to join this project, I would like to start by convincing our managers or product managers or anyone how much time do we waste resolving production issues and how many of those production issues could have been avoided if we simply had an end-to-end test or some other tests, unit tests, and so on.

Right. That sounds good to me. And I know that I wanted to do that so many times when things broke in production and I was working with customer projects and then you would get calls to unholy hours to your project manager who then like tries to call you while you're trying to sleep. And how can I convince... So now that I might be the person who's like, okay, I see the problem. I want to write tests. I learned how to write tests and I now know where to start. How do I convince my team to a, join the effort and b, also how do I convince my manager that I'm not like slacking off and not spending time on something that's useful? I can take this one because I actually have a blog post around the same idea. So there's a couple of things around here. First up, you shouldn't have to convince your manager, product manager or anyone really, because the same way I don't have to convince my manager that I would like to use your state or use effect or any other hook from React. I consider testing to be a part of the thing that I'm trying to deliver. In other words, I, as a software engineer, I am getting paid to not only build and ship software but also ship software that actually works and brings value to our users. Ideally, I would love to get paid for shipping broken software but that's not how the world works. But in a more realistic scenario in which you have a legacy code base and nobody's writing any tests and you would like to create this test setup and to pave the way for future generations who are going to join this project, I would like to start, honestly, by convincing our managers or product managers or anyone how much time do we waste resolving production issues and how many of those production issues could have been avoided if we simply had an end-to-end test or other tests, unit tests, and so on. Because, for instance, consider a website like Twitter. If on Twitter the login page is broken, you literally cannot do anything because it's like outside of... If you are locked out of Twitter, like Twitter is not really... I mean, you can of course read the tweets, but you cannot tweet, you cannot add anything to the platform, and with only this one test in place, you are able to ensure that, okay, by the way, we are absolutely convinced that the huge part of our website is at least accessible to our users. So start with not the fact that I want to write tests, but talk instead about I want to ensure the quality of our software because people are scared of the word tests but they tend to like the word quality a bit more. But what if then your manager asks, well, why are you writing broken code in the first place? Right? I know the answer to that is like, that's something that I have been asked. Sure. I didn't really have an answer. Sure. I would say that I don't write broken code. My colleagues, they also don't write broken code, but all of us combined tend to produce like something that can be broken. So I would like to say that everybody tries to do their best, but sometimes things just happen. And it's not anybody's fault that something is going to break in production. And by us having the best process in place that we can, we can ensure the utmost quality of our software in production. I think that's a good point. Having a process is key and is something that managers also usually do understand because you usually have a process already, at least for project management purposes or product planning, there should also be a quality assurance process, I guess.

But in a more realistic scenario, in which you have a legacy code base and nobody is writing any tests and you would like to create this test setup and pave the way for future generations who are going to join this project, I would like to start by convincing our managers or product managers or anyone how much time do we waste resolving production issues and how many of those production issues could have been avoided if we simply had an end-to-end test or some other tests, unit tests, and so on. Because for instance, consider a website like Twitter. If on Twitter the login page is broken, you literally cannot do anything because if you are locked out of Twitter, like Twitter is not really- I mean, you can of course read the Tweets, but you cannot tweet, you cannot add anything to the platform. And with only this one test in place, you are able to ensure that- Okay, by the way, we are absolutely convinced that the huge part of our website is at least accessible to our users. So start with not the fact that I want to write tests, but talk instead about I want to ensure the quality of our software. Because people are scared of the word test, but they tend to like the word quality a bit more.

Well, what if then your manager asks, so why are you writing broken code in the first place? Right? I know the answer to that is like, that's something that I have been asked. Sure. I didn't really have an answer. Sure. I would say that I don't write broken code. My colleagues, they also don't have broken code, but all of us combined tend to produce something that can be broken. So I would like to say that everybody tries to do their best, but sometimes things just happen. And it's not anybody's fault that something is going to break in production. And by us having the best process in place that we can, we can ensure the utmost quality of our software in production.

I think that's a good point. Having a process is key and is something that managers also usually do understand because you usually have a process already at least for project management purposes or product planning. There should also be a quality assurance process I guess. Also, another interesting question that does come up is when we do start to write tests, especially on a legacy code base, but like the legacy code base also still is alive and still is evolving, then sometimes you end up with situations where the website is perfectly fine. It's just the tests are failing. How do you deal with that? Is there anything you can... any patterns that you can spot in test code that you want to probably avoid to not end up in situations where you create tests that sometimes fail, sometimes pass with no changes in the code made, or there's small changes in the code, but not really in the functionality, but still the tests don't pass anymore? Is there any anti-patterns that I should be looking for in my tests?

Also, another interesting question that does come up is when we do start to write tests, especially on a legacy code base, but the legacy code base also still is alive and still is evolving, then sometimes you end up with situations where the website is perfectly fine, it's just the tests are failing. How do you deal with that? Is there anything that you can, like any patterns that you can spot in test code that you want to probably avoid to not end up in situations where you create tests that sometimes fail, sometimes pass with no changes in the code made or like there's small changes in the code, but not really in the functionality, but still the tests don't pass anymore. Is there any anti-patterns that I should be looking for in my tests?

I think I can take this one. I would say if you have tests that keep failing over and over and over again, you're probably testing something that is internal to the component that you're testing. So rather than testing how other components communicate with you, you're testing something internal, like maybe you're testing that this exact function is being called, but then you change which function is being called to your test breaks and really what you should be testing is this displayed to the user or is this API being called? It shouldn't be the detail of how you implement it, it should be the end result that you should be testing. Right. Okay, cool.

And you said that a valid point to start are E2E tests, but that raises the question, what do you use for E2E tests, for end-to-end testing and web applications? I don't know about everyone. I know Tomasz's opinion on this, but I'm a huge fan of Cypress. I've been using Cypress for a very long time, and it's fantastic, it has such a great developer experience. That's the biggest reason that I use it. There's Puppeteer, there's TestCafe, there's Selenium, and there's various others. But of all the end-to-end testing software that I've used, Cypress is by far in a way that has the best developer experience, and that's what you really need out of a testing tool. Anything can throw an error when there's a problem, but not every testing tool is capable of helping you identify what's causing the problem, which is really critical when a test is failing. That's fair.

Interesting question follow up on this one. End-to-end testing on browsers, I kind of know what to do, but what if I have a mobile app? If you have a React Native app, the one tool that we're using is Detox. It works somewhat similar to Cypress. It is super annoying to set up, I have to admit. I think it took us two days, so the DX isn't great. But once you get it working, it actually does its job quite well. It's a bit of a different experience, just because you don't have a browser, but it's running in the simulator. If I remember correctly, I haven't actually written into SSS in a while. But syntax-wise, it's very similar to Cypress as well. I see. Cool.

And with the testing tool conversation, comes something else. Because, Kent, you mentioned a bunch of tools already. And I have at least the feeling that's similar to JavaScript frameworks a couple of years back, where they popped up like mushrooms in autumn in a Zurich forest, which there are many, if you haven't been. I think testing tools evolve quite quickly as well.

I would say if you have tests that keep failing over and over and over again, you're probably testing something that is internal to the component that you're testing, so rather than testing how other components communicate with you, you're testing something internal. Maybe you're testing that this function is being called, but then you change which function is being called, your test breaks, when really what you should be testing is, is this displayed to the user or is this API being called? It shouldn't be the detail of how you implement it, it should be the end result that you should be testing. Right, okay, cool.

And you said that a valid point to start are E2E tests, but that raises the question, what do you use for E2E tests for end-to-end testing in web applications? I don't know about everyone, well I know Tomas's opinion on this, but I'm a huge fan of Cypress, I've been using Cypress for a very long time, and it's fantastic, it has such a great developer experience, that's the biggest reason that I use it, there's Puppeteer, there's Test Café, there's Selenium, and there's various others, but of all the test end-to-end software that I've used, Cypress is by far a way that has the best developer experience, and that's what you really need out of a testing tool, is, you know, anything can throw an error when there's a problem, but not every testing tool is capable of helping you identify what's causing the problem, which is really critical when a test is failing.

And with the testing tool conversation comes something else because Ken, you mentioned a bunch of tools already. And I have at least the feeling that similar to JavaScript Frameworks a couple of years back where they, like, popped up like mushrooms in autumn in a Zurich forest, which there are many if you haven't been. I think, like, testing tools evolve quite quickly as well. And there's, like, at least a bazillion, bajillion different test runners. And every couple of years, our opinion changes on what's the best of them. And I feel the same like a couple of years back. We had Selenium and everyone was happy and then everyone hated it and then everyone jumped to I can't even remember what the bits and pieces in between work were called. But now we're in Cyprus. Once you are committed to a solution, should you, like, stick to it or should you pretty much, like, continue to, to evaluate and jump on the bandwagon? What's your opinion and experience?

And there's at least a bazillion, bajillion different test runners. And every couple of years, our opinion changes on what's the best of them. And I feel the same way. A couple of years back, we had Selenium and everyone was happy. And then everyone hated it. And then everyone jumped to I can't even remember what the bits and pieces in between were called. But then now we are in Cyprus.

Once you are committed to a solution, should you stick to it? Or should you pretty much continue to evaluate and jump on the bandwagon? What's your opinion and experience?

I can take this one. So when it comes to testing solutions, in my humble opinion, the landscape is a bit settled, at least for me, because I'm using Jest. I'm using React Testing Library written by Kent, and I'm also using Cyprus. So I am quite convinced that this stack is going to take me to great success in the software that I'm building. But when it comes to chasing this bandwagon and when the next better version of something for end-to-end testing is going to be released, for instance, I am not entirely sure whether you should jump on a bandwagon right away. I tend to think of software in the way that if something is solving your problems and you don't get any issues because of the fact that you are using a certain library, I don't think you should necessarily have to, you know, jump to a better testing solution. Although, if, I don't know, in the next testing solution, it will be, you know, twice as fast or the test will be written by an AI. I would be definitely interested.

Fair. I think, yeah, I think that's a good... The fewer tests that I have to write to be confident in my software, the better.

Exactly. I don't write tests because I enjoy writing tests, I write tests because I like to be able to ship software and be confident that it's working. So if I don't have to do that, if I don't have to write the tests, then I'm totally fine using some AI that does that for me.

Yeah. Same goes for Angular code for the record.

Yeah, that too. That's true. Yeah, I think everyone agrees on that.

Speaking of less tests or fewer tests, if I have unit and integration tests as well as end-to-end tests, can I just scrap these asks, Eluned, from the chat? Can I just stick with end-to-end tests? Because, I mean, they are the closest to what the customer actually gets to interact with, right?

I'm happy to take that one, and in my experience, your end-to-end test is never gonna check all edge cases, especially when it comes to interactions between components. I mean, if your end-to-end test does catch all edge cases, that's, A, very impressive, and B, the suit is probably gonna run for hours because it's really hard to figure out all the different combinations of component interactions. So don't scrap the tests, especially if they pass and then do their job, then leave them in. But when it comes to writing your tests, my general thing is, I go for more an integration-y kind of test than actual unit tests because you very rarely just have one component on your screen, right? It's always about components are interacting with each other.

I see. Cool. And with the testing tool conversation comes something else because Ken, you mentioned a bunch of tools already. And I have at least the feeling that similar to JavaScript Frameworks a couple of years back where they, like, popped up like mushrooms in autumn in a Zurich forest, which there are many if you haven't been. I think, like, testing tools evolve quite quickly as well. And there's, like, at least a bazillion, bajillion different test runners. And every couple of years, our opinion changes on what's the best of them. And I feel the same like a couple of years back. We had Selenium and everyone was happy and then everyone hated it and then everyone jumped to I can't even remember what the bits and pieces in between work were called. But now we're in Cyprus. Once you are committed to a solution, should you, like, stick to it or should you pretty much, like, continue to, to evaluate and jump on the bandwagon? What's your opinion and experience? I can take this one. So when it comes to, like, testing solutions, in my humble opinion, the landscape is a bit settled, at least for me, because I'm using Jest. I'm using React Testing Library, written by Kent, and I'm also using Cyprus. So I am, you know, quite convinced that this stack is going to take me, you know, to great success in the software that I'm building. But when it comes to chasing this bandwagon, and I know when the next better version of something for end-to-end testing is going to be released, for instance, I am not entirely sure whether you should jump on the bandwagon right away. I tend to think of software in the way that if something is solving your problems and you don't get any issues because of the fact that you are using a certain library, I don't think you should necessarily have to, you know, jump to a better testing solution. Although if, I don't know, in the next testing solution will be, you know, twice as fast or the test would be written by an AI, I would be definitely interested. Fair. I think, yeah, I think that's a good... The fewer tests that I have to write to be confident in my software, the better. Exactly. I don't write tests because I enjoy writing tests. I write tests because I like to be able to ship software and be confident that it's working. So if I don't have to do that, if I don't have to write the test, then I'm totally fine using some AI that does that for me. Yeah, same goes for AngularCode, for the record. Yeah, that too. That's true, yeah. I think everyone agrees on that. Speaking of less tests or fewer tests, if I have unit and integration tests as well as end-to-end tests, can I just scrap these asks, Elonate, from the chat? Can I just stick with end-to-end tests? Because they are the closest to what the customer actually gets to interact with, right? I'm happy to take that one. In my experience, your end-to-end test is never going to check all edge cases.

So I think KenTest is a really pretty testing trophy, which is mostly end-to-end tests and integration tests and all the stuff that is just super weird tests, that's when you do unit tests. I mean, generally, I'm also a very lazy person. So if I can cover all the edge cases with integration tests, why would I write unit tests, right? That's just more code I have to write and more stuff I have to maintain later on. That's fair. But I think the speed aspect is one that's important. Sorry. It's flakiness as well, I think. End-to-end tests do tend to be a little bit flaky sometimes because there are so many different systems at play, right? So going a level lower already helps a lot with that because all of a sudden you're only testing your part of the application rather than also the interaction with seven different backend services. So that can help. And then I actually love unit tests as well, but I use them not as much for React components, but more for, say, all of my different functions that do stuff, like all the library stuff that is just somewhere tucked away, right? Well, unit tests are perfectly suited.

In my experience, your end-to-end test is never going to check all edge cases. Especially when it comes to interactions between components. If your end-to-end test does catch all edge cases, that's A, very impressive, and B, the suit is probably going to run for hours because it's really hard to figure out all the different combinations of component interactions. So don't scrap the tests, especially if they pass and do their job, then leave them in.

But when it comes to writing new tests, my general thing is I go for more kind of test than actual unit tests because you very rarely just have one component on your screen. It's always about components interacting with each other. So I think KenTest is really pretty testing trophy, which is mostly end-to-end tests and then integration tests and all the stuff that is super weird tests. That's when you do unit tests. Generally I'm also a very lazy person, so if I can cover all the edge cases with integration tests, why would I write unit tests? That's just more code I have to write and more stuff I have to maintain later on.

Another thing to think about is flakiness. End-to-end tests do tend to be a little bit flaky sometimes because there are so many different systems at play. So going a level lower already helps a lot with that because all of a sudden you're only testing your part of the application rather than also the interaction with seven different back-end services. So that can help. I actually love unit tests as well, but I use them not as much for React components but more for all of my different functions that do stuff, like all the library stuff that is just somewhere tucked away. For that, unit tests are perfectly suited.