 So, okay. I'm Sushi. I'm Sushi. I'm talking about the testing framework today, which looks a lot like Perl, but actually isn't. It's written by David Weeler, which you may know from, for example, Regoulash, and he has written a very nice testing framework, both for Postgres and for MySQL. And it's basically a unit testing framework for databases. So, it doesn't run really on Perl, but it runs standalone on whatever database you've got, if it's Postgres or MySQL. You just install it and then write tests. And this is where the interest about Perl comes in, because it's for data's top-based framework. So, if you actually run it, it looks completely familiar. So, anything you see here doesn't really look differently from anything you've got from Testmo, for example, or anything else you're using in Perl. So, the interesting part with the Postgres framework is, it's very similar to the way Perl testing works in general. And I think Perl testing is very, very nice, because it's very cheap to do based on the simple things like, okay, isn't unlike, unlike compare things, you can whip up a lot of very nice tests, which are actually not stupid at all, even though they are really, really simple. So, also, Perl testing exists on literally every level of software you can imagine. For example, in my last job, I've written a test framework which was based on TestDB Selenium to simplify re-testing over a couple of browsers running on different coasts to test a very large web-based re-application, for example. You can also simply test somewhere in the middle, all kinds of things. You can test databases via DVI or via DVX class, of course. So, what you've got in Perl's testing culture is this very cheap and easy and fast, it's easy to learn, it's really fast to write, for example. So, you just sit down and whip up a couple of dozen of tests. For this simple presentation, I've written 45 tests, for example, in, I don't know, six hours or something like this. So, this is something what David Wieler's tool reflects very much. So, if you're used to Perl testing, you will immediately ease into a big eta and my top-risk. So, what you're doing is you look at your database and a database usually has really a lot of things. It has a couple of databases, I think, it has shemas, it has roles, groups and users, grants and permissions. It has, of course, your tables and your columns. It has types and checks and constraints, sets, indexes and sequences. You write, for example, in postcards, lots of functions in different languages, of course. You write your triggers, your set of views and, of course, you actually do stuff with your data, namely, selects, inserts and updates, of course. And this is all wrapped into the testing framework. So, you can write tests on all these levels of the database, depending on how you look on your database. You might focus on totally different things. So, on a very simple level, you create a table and the table has stuff on it in some way or another and you just start testing for simple things like existence. Is the table actually there? This is in postcards, the simple public schema. If you don't create your schema, you just work on the public schema. You just create, for example, some role with specific grants and permissions and you just ask all your tests if these things are really there. And if you look at this, just ignore this part, for example. It's basically just the same which you know from testing off, for example. So, all the language we're used to in our testing has, is, can, isn't, equals, not equals. All the stuff is all the same way here. So, if you go a little bit deeper and look at a specific table, for example, created the usual primary key, maybe that check and some default setting, you start asking a little bit deeper if the table actually has checks, for example, if your columns are these specific columns. If the table, for example, has a specific sequence, because you're using serial and the serial creates automatically a sequence for this specific table. So, you run all these tests. And if you run these tests, for example, stand alone without, so this is, if you run it with David Wheeler's proof, which is specific postcards proof, it's not the proof, proof, we already know. This is the usual pile style output you get. But you can also just run it directly via the PSA command line. And this is what you get if you bypass the proof concept, for example. So, if you look at this, you're basically calling in a postcards database functions and get this as a result, or you call it in top style. So, it really actually works in all kinds of CV and CI tools like Jenkins, whatever you've got. So, if you look a little bit deeper, even more onto your columns, for example, you have all kinds of checks here as well. You're asked, for example, if your column is actually a primary key, if your column has to be not null, you're asked, of course, because we're in the database, you're asked a lot for types. So, if you start writing tests, it will have, of course, a lot of checking up on which type your column actually has. So, this is something, this is, of course, different in database stuff than in poly, you have to care for your types. And if in doubt, specifically, your postcards return stuff, you really have to look up what postcards functions, for example, specifically return because you later need for comparison the very exact type. This is one little nuisance because if you're not used to it, you get usually wrong. So, your test, for example, for the key relationships, this is basically a shortcut, which says if this table has this column, and this refers to this table and this column, so you can test in one, simply test the actual relationships between your tables. And this is, for example, very nice because at some point you've got a lot of them. So, then you'll go a little more specific and test, for example, for specific checks. I've made a capital out of this where you have to put in the country code as two characters, and if you insert dates, it's automatically diversity. It assumes you're kept born to dates. You check, you test for the usual column type, of course, you test for if the column has a specific check on, if this table has a check on this specific column, you will ask, for example, for default names. You usually create a lot of, if depending on your tables you create, of course, a lot of default variables to make things easier. So, this, of course, you can test and then you can test what kind of default you may have on some column. So, you're all run-less, you get the usual top output or not, and then you can, of course, test in triggers, so which are sometimes a combination of a function you can test and of a trigger where you test if you've got the trigger assigned together with this function. So, this is the simplest thing I could come up with, so you're creating a timestamp trigger and assign it to a specific table so that every time a cat gets updated on its trace and characteristics, you create the usual updated information along with it. So, you're asked here if this function actually exists, for example, because Postgres supports so many languages, you can use Parallel in Postgres, Node.js in Postgres, Python in Postgres, PNAS in Postgres, and I think L right now is also available in Postgres. So, you're going to ask if this URI language, the function is written in, you can, of course, ask what the function returns, this is what you expect, and then you ask if the trigger is assigned properly together with the function you've just written. So, you're getting more and more deeper into what your whole database consists of, and in the end, if you are leaving out a lot of options here, for example, the whole branch and rule the rules and permissions thing, you can test all this too. I will say a word about testing of indexes, for example, it's a whole, your own world, how much indexes you use, and how you're using them in that test form of this. So, in the end, you go, of course, to actually handling data. So, if you have your table, and if your table has, for example, this little checkbox, you're expecting two things to test, you're expecting a valid insert, which isn't supposed to affect it, but of course, you also want to test if your checkpoints will actually reject the start-up. So, you usually start to test these things in pairs, one valid thing which you expect to succeed, which is like, okay, so, inserting the new cache, it's going to be okay, and then you test, of course, the opposite flows, okay. So, you're inserting something invalid, deliberately, and expect the specific return, what you're violating. So, if you, you can test, of course, a lot of things more on this. For example, if I would have a function which checks if the country code is a valid country code, for example, a valid top-level domain, or a valid easel country code, or whatever, we assign as a valid code, I could write a function and another check, for example, to it, and also test all the flows I can think of. Especially in Europe, I'm writing a lot of unicode and upload failure flows, so that you either data somewhere, which doesn't contain a certain range of characters, for example, or just weird characters. So, this is all, in the end, it's testing for your data consistency more or less. So, then, of course, if your insert succeeds, you actually try to select things. So, and this is where you write a prepared statement, so you select this case, and you test on the results, and here it gets, for example, the type really important. So, whatever you assign to your column has to be reflected here. So, and then there's a different variety, how you test your results. If you really use results, it means you get it back in an ordered, in an unordered way, but you're checking for an order. So, if you don't use here something on your statement, you need to, for example, use a set or a bag instead. If ordering your case doesn't matter, if you're expecting more than one result, if, for example, you have, you expect valid duplicates if they don't matter, if you expect valid duplicates if they're supposed to be specific duplicates. So, there's a whole lot of variety in it, how you can actually test your selects. And the very nice thing, which is, of course, database relevant, is her forms, okay. You write a test where you would say you expect that this really doesn't take longer than six milliseconds and run the test on it, which is, of course, a very nice thing for a database to do, yes. So, this is a variety of testing stuff you get, or with a simple create extension on the Postgres. Which you simply get by installing the code from, Postgres has a very tiny queue with a cpun thingy where you can download extensions. And you just install it by, you install it, and then create the extension gata on the database. And just have it. If you install the new proof, which is actually on the cpun, along with it, you get the nice and shiny top output you're used to. But you don't have to depend on the different testing side, the usual, similar to the testing side, which they really have checked out. It's not a limitation. So, what makes Piggy top so nice to use is that you actually just look up a lot of tests. So, and that's not even complete testing of the two super simple tables I've written before the presentation. It's just chunks of it. So, I'm only testing, for example, two columns and not all of them. And failing tests are specifically interesting to capture. Because if you have, you're able to test for not just existent, if something is there, but you're also able to test if specifically only this is really there and not more. So, if you're testing, for example, for your columns, you can use testing functions in Piggy top, which exclude additional columns which are found, but you're not testing for. So, you can say, do I actually have this column? But you can also say, I don't want to have more than those columns. So, there's a whole lot of viewpoints involved to test. So, looking at things you actually have or things you actually don't want to have, things you want from your results and things you want to really want to fail and test for, that's really nicely done. Someone asked for speed and this is of course your selects and inserts and all the queries take as long as they usually take, of course. But all in all, if you run the whole shebang of a couple of hundred tests, it's really fast. It takes seconds. What is not included in Piggy top is the whole testing concept, how you deal with testing and databases. So, do you use a backup copy and test on this? Do you use your production database and test on this? Are you writing, do you set up a whole new database and add only fake test data in it? Someone else asked for SQL light support because a lot of people work on their database tests in SQL light and just throw some data in, set it up and tear it down and throw it just away, which is so far not possible because I think there is no top form that's really not yet, but I'm pretty sure. What? Jesus. Okay, yes, yes, yes, I'm done. So, this is just, we're using this on office code and I'm around 600 tests for some final and it's really, I can highly recommend it. It's very nicely documented. It's really, really easy to learn. Everybody can go out a couple of tests. This column has, that column, it has this restraints. So, if you're focusing on functions, for example, gets a little bit more complicated, but it's all perfectly easy to learn. It's a half day's work, not more. So, I would be happy if you start using it because very few people so far actually do. So, it's good. Okay, one second, yes.