 I hate regressions, especially when I am to blame. Cisco's use of the Office Interability Testing Suite has been invaluable for finding my regressions, but I would prefer to notice them before my name ends up in a bug report. So in this talk, I want to share my recent practice of asserting defined existing unit tests that will be impacted by each patch. We want to, of course, fix the problem and not just the document that we're working on. And so once I have my patch developed, I add some debug output and assert to find examples of the documents that will be affected by the change and then run a make check. So in the example that we're going to discuss today, we have the top part of Microsoft document. It says, hello world and a table cell. And you'll notice there's no spacing at the bottom underneath word, because it has contextual spacing, which says that if it's the same paragraph above and below, then you don't add the spacing to it. And so in this case, hello has a spacing above, but world doesn't have any spacing around it. In Labor Office, we add spacing below at the bottom. Our theory is that the bottom of a cell, we just ignore the contextual spacing just like you would at the end of a document. And so we have here the adding of the additional space of the lower, but in our case, when it's a doc x and it's contextual spacing, then we don't want to add anything at all. And so we're going to assert the case when we would have a nonzero value that we're adding to the lower part. By running a make check, we found a number of examples and this one was a very clear one that does show some spacing at the bottom of a cell. And so that proves that our theory is not complete. And it actually ends up being a very complex thing. They are logical in the way that they do it, but their logic is not expected and not at all similar to the way that Labor Office does things. And notice that the first cell sometimes has spacing and sometimes doesn't, depending on what occurs outside of the table before it. And the same thing is true on the bottom, although in a different way. And the cells are also not independent. They depend on the cell before them. And the special situation at the end of a row. So some of the lessons that I've learned in doing these asserts is that first, make sure that your assert of course works on the your bug report example. Too often for me, I forget to do that and I have my assert logic wrong and I waste all that time running a check with a broken assert. It's also good to add some debug output before your assert. That can help you with a number of things, including identifying the location of the instance where it's happening in a large document. Can also hint about the need for better asserts that you might need. You might need to assert for a few more conditions or avoid a few more conditions. And can also help you determine whether a document is even worth investigating more if it's just a tiny spacing change in this example. It might not be worth even looking at the document. If there are no matching examples, you probably forgot to do step number one and have a bad assert. If there are too many examples, try to assert only on the interesting or highly visible examples. One nice thing that this can do is you can find unit tests that exhibit the bug that you're fixing. And then you could perhaps use that as your unit tests instead of creating a new one and avoiding a load save operation. So for example, in this document, we might only be interested in a larger space, a greater than 100 instead of just a non-zero space. Delete the unit tests that you run into so that you can run the make check again. And once you hit check in a certain area or a folder, run the tests in that folder sequentially and not in parallel. So you can do that with a make check with the brackets as defined there and I'll run each one one after the other and stop if it ever hits a matching test and then you can just continue on again from there. And then I've also been uploading the patch with all the asserts and the deleted unit tests as a work in progress patch to Garrett. And that is nice for documentation. So if you upload it as a percent WIP, then it doesn't run any Jenkins tests on it. And so you're not wasting TDF infrastructure time on it. In these cases, I also try to add a reply to the commit indicating that the patch that contains documentation, otherwise, it'll probably get lost. It does take a lot of time and effort to run the make checks, but I think the results end up being worth it. And it's helped me a lot to avoid regressions. Thanks.