Testing Q&A

[00:00:00]
>> Speaker 1: Where would you kind of draw the lines as far as writing tests or test-driven development around SQLite?
>> Brian Holt: I was literally talking about this with my boss yesterday.
>> Brian Holt: You don't have to test SQLite, it's extremely well tested. Dr. Hipp is obsessive with the test that he writes, and I mean that in actually an admiring way, that he writes tester to test his software extremely well.

[00:00:31]
I think it's part of the reason they don't accept outside contributions, is because they're obsessed with keeping it so battle tested. So, if I call this select, do I get the correct thing back from the database? I'm not testing that, right? I'm assuming that SQLite is going to continue to be extremely reliable.

[00:00:56]
If you have strong business logic tied into your database, which you can using things like constraints and triggers and functions and all sorts of wild things, much of which we're not gonna talk about today, because I don't think a lot of that stuff belongs in a database. Then you'd wanna write some integration tests to make sure that your business logic that you're providing to SQLite to run on your behalf, run the way that you expect them to.

[00:01:23]
So, I would test that. Beyond that, most of the danger is in your code, right? So I'm much more into the unit test of make things modular, make them self-contained where possible, and then pull them out and test them individually. The nice thing about SQLite is it runs anywhere.

[00:01:39]
It can run inside of GitHub actions, it can run in circle, Jenkins, wherever. So you can just spin up a database, run a bunch of tests that call and hit the database. It'll be very fast, you don't have to worry about latency or anything like that, or tear down or anything like that.

[00:01:55]
So those are kind of like they're almost integration tests, I guess, there's two different pieces working together, but it's a library at that point, right? So, I wouldn't be too amiss to just go ahead and write those tests using the SQLite database. Perhaps one of the strongest arguments for SQLite is that these kind of scenarios are really possible, that you can have just a normal, vanilla copy of SQLite running locally.

[00:02:23]
That you read and write to a bunch of times for your local development cycle, and then you push into the your Git repo that then deploys, and then it calls something like tersa or SQLite cloud or something like that. That's a really good workflow, that works really well for me, and it tests very well.

[00:02:44]
So, that's kind of some unsorted thoughts about what I think about testing with SQLite. Don't test the database itself, test your code, and if you have heavy lifting being done in your database, then test those two.
>> Speaker 1: So, [COUGH] like in a pipeline, you would just install a new instance of SQLite as part of a workflow?

[00:03:15]
>> Brian Holt: Basically, I mean, essentially what I would do is, this is the app that we're gonna be working on here in just a little bit. You can see I include here data.db. I might just include a test.db, preceded with a bunch of valid data, script of PII and stuff like that.

[00:03:33]
And then all of your tests can just obliterate that database and not check it in, right? And so you can just think run all your tests, no problem.
>> Brian Holt: Pretty hot, right? Like, it's so much easier to not have to spin up a version of your database and do a bunch of tests by that and then throw it away and then re instantiate it, and all that kind of stuff.

[00:03:54]
Yeah, that workflow works really well with SQLite.