WEBVTT 00:00.000 --> 00:07.000 You're not going to talk about red fun, will you? 00:07.000 --> 00:11.000 No, sorry, I'm just going to teach it, but no, I'm not talking about it. 00:11.000 --> 00:15.000 Jake was going to really, really, really awesome demo about the red fun, the jack one 00:15.000 --> 00:18.000 and how they read it today, I. 00:18.000 --> 00:20.000 This talk is not about that. 00:20.000 --> 00:25.000 There'll be something about talking, but it also is to read to me, so let's see. 00:25.000 --> 00:26.000 Cool. 00:26.000 --> 00:34.000 OK, so broken docs can be a nightmare, whether you're a tech writer, a developer or a product manager. 00:34.000 --> 00:39.000 They wrote your trust, they wasted a time, and they make your product look kind of immature. 00:39.000 --> 00:47.000 But we're here today still about Dr. Detective, which can turn your docs from a source of pain to a delight through robust automated testing. 00:47.000 --> 00:53.000 I'm Jake, I'm from Red Panda Data, which is a streaming data platform. 00:53.000 --> 01:02.000 And we're starting to integrate Dr. Detective into our docs, so to get testing and output and automated testing. 01:02.000 --> 01:03.000 Yes. 01:03.000 --> 01:11.000 And I'm Ariel, I'm a technical writer at Samarky, where a data management integration and governance company. 01:11.000 --> 01:18.000 And I'm starting to look at Dr. Detective to also test our docs and help keep them up to date. 01:18.000 --> 01:20.000 Cool. 01:20.000 --> 01:24.000 All right, so this is just the truth, something always breaks. 01:24.000 --> 01:30.000 So imagine your company to support the shiny products, and you've been tasked to set it up and configure it. 01:30.000 --> 01:36.000 This is a product that's like, it's promised to solve all your company's problems. 01:36.000 --> 01:40.000 So you might start by feeling cautious the optimistic. 01:40.000 --> 01:46.000 You start researching just to see what this product does, and you might stumble across some docs. 01:46.000 --> 01:55.000 So things are looking pretty good. The docs even have a guide for the exact problem you're trying to solve. So you're confident. 01:55.000 --> 02:05.000 This guide has step-by-step instructions, copy paste commands, and you copy paste the first command into a terminal hit enter and it gives you an error. 02:05.000 --> 02:11.000 At this point, you probably lost all trust in the rest of the doc, and you're not going to continue reading. 02:11.000 --> 02:18.000 And this is a common occurrence, because keeping docs in sync with a product that's constantly changing is hard. 02:18.000 --> 02:20.000 Can you repeat that? 02:20.000 --> 02:22.000 I'll talk a little louder. 02:22.000 --> 02:24.000 So yeah. 02:24.000 --> 02:26.000 I hope all the whole thing? 02:26.000 --> 02:29.000 No, just a lot of sense. 02:29.000 --> 02:40.000 So it's common for docs to break, because keeping docs in sync with a product that constantly rolls out new changes is just difficult. 02:40.000 --> 02:45.000 Even a minor change, like changing a button label, or what can seem like a minor change. 02:45.000 --> 02:53.000 Like changing a button label from begin to start, complete the doc, and that's going to erode trust in the rest of your docs. 02:53.000 --> 02:58.000 So we're going to dive into why this happens. 02:58.000 --> 03:03.000 And it's a real challenge. 03:03.000 --> 03:11.000 So one of the big challenges, and this is probably happened to everyone, but actually question, 03:11.000 --> 03:17.000 who here has somehow never dealt with broken documentation? 03:17.000 --> 03:19.000 Ever. 03:19.000 --> 03:22.000 All right, you're in good company. 03:22.000 --> 03:24.000 There are the challenges. 03:24.000 --> 03:29.000 I mean, the biggest challenge at first is that there are lots of updates. 03:30.000 --> 03:32.000 Your product gets features. 03:32.000 --> 03:33.000 Your product gets changes. 03:33.000 --> 03:35.000 Your product gets deprecations. 03:35.000 --> 03:40.000 The libraries your product depends on are deprecated, and you find out later. 03:40.000 --> 03:44.000 And it is a shared responsibility. 03:44.000 --> 03:47.000 So I'm, for example, a technical writer. 03:47.000 --> 03:52.000 I could watch for every single change in the product. 03:52.000 --> 03:54.000 That's not very realistic. 03:54.000 --> 03:56.000 I'm a technical writer. 03:56.000 --> 04:04.000 I don't have the role of project manager who could be responsible for telling me all of the new features that are coming. 04:04.000 --> 04:08.000 But the project manager might not know about changes to existing features. 04:08.000 --> 04:10.000 And that's the engineers. 04:10.000 --> 04:12.000 But the engineers are not writing the documentation. 04:12.000 --> 04:13.000 I am. 04:13.000 --> 04:17.000 So at some point you have to figure out who is dealing with this mess. 04:17.000 --> 04:19.000 How do you get visibility? 04:19.000 --> 04:22.000 Somebody needs to know what's in the documentation. 04:22.000 --> 04:27.000 You need to know what's in the docs to decide if you want to change them. 04:27.000 --> 04:29.000 And there are a lot of moving parts. 04:29.000 --> 04:31.000 You cannot do it perfectly. 04:31.000 --> 04:34.000 And something will eventually fail. 04:34.000 --> 04:36.000 Your users will find out. 04:36.000 --> 04:42.000 And that will cascade into a horrible scenario where somebody realizes something is wrong. 04:42.000 --> 04:44.000 I mean, something's wrong. 04:44.000 --> 04:47.000 What tends to happen is you open a support ticket. 04:47.000 --> 04:50.000 Which leads to longer resolution times. 04:50.000 --> 04:57.000 And generally, if consistently reliable docs build the trust, then inaccurate ones will undermine it. 04:57.000 --> 05:02.000 And that's going to think things like your retention metrics, your satisfaction metrics. 05:02.000 --> 05:05.000 Because building the trust is hard, but losing it is super easy. 05:05.000 --> 05:10.000 So what we want is we want users to read something that just works. 05:10.000 --> 05:15.000 And there is a strategy to enable that and it's called docs as test. 05:15.000 --> 05:21.000 And docs as test is not the name of the of Dr. Techive that we're demoing. 05:21.000 --> 05:23.000 It is a practice. 05:23.000 --> 05:29.000 It's the practice of automatically verifying every step outlined in your documentation. 05:29.000 --> 05:32.000 Which sounds ambitious. 05:32.000 --> 05:38.000 But just imagine for a moment, imagine you have every command, every UI flow, 05:38.000 --> 05:43.000 and every configuration step automatically checked for accuracy. 05:43.000 --> 05:46.000 That is a dream. 05:46.000 --> 05:51.000 But quite honestly, it's kind of the goal and it's what you want to work towards. 05:51.000 --> 05:59.000 So if something breaks, like a command no longer works or UI element changes, the tests catch it automatically. 05:59.000 --> 06:01.000 This is a proactive approach. 06:01.000 --> 06:03.000 It means your docs remain accurate. 06:03.000 --> 06:06.000 It means they remain aligned with the products current state. 06:06.000 --> 06:11.000 And your users and yourself are probably much happier. 06:11.000 --> 06:15.000 Because the chances are you have to use your documentation as well. 06:15.000 --> 06:19.000 And there are existing testing tools. 06:19.000 --> 06:25.000 Docs, sorry, Dr. Techive is an intermediate tool. 06:25.000 --> 06:28.000 It's not for complete novices. 06:28.000 --> 06:31.000 You do still need some knowledge to use it. 06:31.000 --> 06:36.000 But for example, you have tools like Cypress and Playwright. 06:36.000 --> 06:41.000 And you could integrate them into your docs. 06:41.000 --> 06:48.000 But if you are like me and you are not a JavaScript developer and you have to use search engines 06:48.000 --> 06:55.000 or local LLMs to figure out code, this is a lot. 06:55.000 --> 06:56.000 This is a lot. 06:56.000 --> 06:59.000 The two snippets that just came on the screen do the exact same thing. 06:59.000 --> 07:00.000 They test a URL. 07:00.000 --> 07:04.000 They interact with the UI and they take screenshots. 07:05.000 --> 07:11.000 It would be nicer if this were a little simpler to read. 07:11.000 --> 07:15.000 Oh, and that's where the docs tested comes in. 07:15.000 --> 07:23.000 So I'm going to get rid of the slides and just go into a demo. 07:23.000 --> 07:28.000 I think if you want, I can just start in the end. 07:28.000 --> 07:29.000 Yeah, sure. 07:29.000 --> 07:34.000 So Dr. Techive is a testing framework built by many silver. 07:34.000 --> 07:39.000 It is an implementation of the docs to test methodology, 07:39.000 --> 07:43.000 and it aims to make tests much more approachable to technical writers 07:43.000 --> 07:48.000 by writing with JSON objects instead of programming languages. 07:48.000 --> 07:55.000 And in this case, the JSON, how it's presented, is aimed to be a lot more approachable. 07:55.000 --> 07:58.000 So yeah, this is the basic structure of a test. 07:58.000 --> 08:02.000 Yeah, it's just a JSON object and it's made up of step objects. 08:02.000 --> 08:05.000 And each step has an action associated with it. 08:05.000 --> 08:10.000 So here we've got the go-to action, which is a web page or a URL. 08:10.000 --> 08:14.000 We've got a find action that will interact with that web page. 08:14.000 --> 08:17.000 And each action also has properties. 08:17.000 --> 08:21.000 So this find action has a click property that tells Dr. Techive 08:21.000 --> 08:24.000 if you find this element, click it. 08:24.000 --> 08:28.000 And so what you can do is you can aggregate all of these steps up. 08:28.000 --> 08:31.000 So one after the other, they build a robust test, 08:31.000 --> 08:34.000 and it runs through a real user workflow. 08:34.000 --> 08:37.000 So you can define tests in a few ways. 08:37.000 --> 08:40.000 You can have a separate JSON file like this, 08:40.000 --> 08:44.000 but then you have to maintain the test separately to the doc. 08:44.000 --> 08:47.000 So then what you can also do is have in line comments. 08:47.000 --> 08:53.000 So within the document, you just define the steps in the same file, 08:53.000 --> 08:58.000 which means if you update the doc, you can update the test at the same time. 08:58.000 --> 09:03.000 There's a more complex option as well, and you can teach Dr. Techive 09:03.000 --> 09:07.000 to dynamically generate the test steps. 09:07.000 --> 09:11.000 So you basically feed it a bunch of regular expressions. 09:11.000 --> 09:16.000 And you say, if you come across this pattern, this is the kind of step you need to build. 09:16.000 --> 09:21.000 But that does take a little bit more set up, but then it also does mean that you don't need to maintain 09:21.000 --> 09:24.000 the test separately to your documentation. 09:24.000 --> 09:31.000 So, but I think this is the good, a good moment to show you the fun stuff 09:31.000 --> 09:34.000 and show you what it actually does. 09:34.000 --> 09:42.000 We've got a few demos for you, and we're going to start with a very simple demo. 09:42.000 --> 09:45.000 Who likes cats? 09:45.000 --> 09:51.000 Well, and if you don't like cats, I'm sorry you are going to get a cat fact anyhow. 09:51.000 --> 09:58.000 The first demo is a very simple test, if I can briefly show it here as well. 09:58.000 --> 10:04.000 It is a single API call to catfact.ninja slash fact. 10:04.000 --> 10:09.000 All we are doing is trying to see if it gets a valid response. 10:09.000 --> 10:29.000 Dr. Tech Dev is reading the input, reading catfacts, and done. 10:29.000 --> 10:36.000 Now, the terminal is a little bit small here, but it outputs it test results in a JSON file here, 10:36.000 --> 10:46.000 well, formatted, which shows you how many of the steps and tests actually worked. 10:46.000 --> 10:49.000 For the detail, and oh look, this is our actual response. 10:49.000 --> 10:53.000 Did you know that cats been nearly a third of their waking hours cleaning themselves? 10:53.000 --> 10:57.000 And did you know that this fact is 64 characters long? 10:57.000 --> 11:03.000 Well, we have this here, but the big thing is that we got a 200 response. 11:03.000 --> 11:09.000 So, this test passed, which is exactly what we wanted. 11:09.000 --> 11:12.000 We will move on to test number two. 11:12.000 --> 11:18.000 Sorry, demo number two, which I actually labeled as one. 11:18.000 --> 11:22.000 And this one actually uses some inline checks. 11:22.000 --> 11:29.000 We've got some makeshift markdown comets here, with the actual JSON for the test. 11:30.000 --> 11:33.000 We're going to check it URL. 11:33.000 --> 11:40.000 Check another URL, check URLs, go to URL, and then do something a little bit better. 11:40.000 --> 11:44.000 We're going to save a screenshot. 11:44.000 --> 11:58.000 And if the internet connection here works well, we will launch a library Chrome session, 11:58.000 --> 12:03.000 which took the script. That worked faster than on my computer. 12:03.000 --> 12:08.000 And that was automatically taken by Dr. Tech Dev, 12:08.000 --> 12:12.000 without needing our manual input when the test was running. 12:12.000 --> 12:17.000 You can imagine running this multiple times, or running it in a continuous integration, 12:17.000 --> 12:24.000 and continuous update system. 12:24.000 --> 12:33.000 Test number three or two is going to be a little bit different. 12:33.000 --> 12:38.000 We are detecting tests automatically. 12:38.000 --> 12:47.000 Here, we don't actually have any statements, but there are some pre-configured checks here, 12:47.000 --> 12:51.000 or markdown files, and which amount of things will check the links. 12:51.000 --> 12:59.000 Let's run this here. 12:59.000 --> 13:04.000 There we go. Once again, we are loading this in Chrome. 13:04.000 --> 13:14.000 This is a Chrome that's been pulled by a JavaScript library, specifically for this kind of work. 13:14.000 --> 13:17.000 Same image. No problem. 13:17.000 --> 13:20.000 And the test output worked. 13:20.000 --> 13:23.000 It used the Chrome application. It was on a Mac. 13:23.000 --> 13:26.000 It checked the links. 13:26.000 --> 13:28.000 You can read through all this if you want. 13:28.000 --> 13:32.000 It found an element matching a selector. That's fantastic. 13:32.000 --> 13:35.000 And it took a screenshot, and better than that. 13:35.000 --> 13:40.000 It checked whether the screenshot varied enough from the last time the screenshot was taken, 13:40.000 --> 13:46.000 which means you can actually use this to keep your internal screenshots up to date. 13:46.000 --> 13:48.000 See if your application has changed enough. 13:48.000 --> 13:51.000 Well, warn you if there's a problem. 13:51.000 --> 13:57.000 But my favorite test here. 13:57.000 --> 14:01.000 So, in keeping with the cat theme, 14:01.000 --> 14:07.000 how about we actually do a little bit more of a recording? 14:07.000 --> 14:15.000 We can also do some basic screen recording here, 14:15.000 --> 14:18.000 in which we're going to open a website. 14:18.000 --> 14:24.000 And we're going to search for kittens. 14:24.000 --> 14:28.000 Hey, we found them. 14:28.000 --> 14:42.000 And the end result is an actual animation. 14:42.000 --> 14:44.000 You can also use Dr. Tech. 14:44.000 --> 14:45.000 For screen recording. 14:45.000 --> 14:48.000 If you have steps that your users need to follow. 14:48.000 --> 14:51.000 For example, you could record the key presses. 14:51.000 --> 14:53.000 You could record all the different steps, 14:53.000 --> 14:56.000 and show it as an animated image afterwards. 14:57.000 --> 15:00.000 And this is the start. 15:00.000 --> 15:04.000 Because we can do more with this. 15:04.000 --> 15:05.000 Cool. 15:05.000 --> 15:10.000 So, I just want to show a real world example now, 15:10.000 --> 15:15.000 which is a repander we've built this into one of our quick start 15:15.000 --> 15:17.000 for a product called Repandiconso. 15:17.000 --> 15:21.000 So, this is a UI, so it needs some screenshots. 15:21.000 --> 15:24.000 We don't really like to have screenshots in dots, 15:24.000 --> 15:26.000 because they're quite expensive to maintain. 15:26.000 --> 15:28.000 If something changes, you have to go in. 15:28.000 --> 15:30.000 Set out the virtual environment again. 15:30.000 --> 15:32.000 Take the screenshot and it's hard. 15:32.000 --> 15:37.000 So, I just want you to notice here that the version here is 24.3.1, 15:37.000 --> 15:41.000 which is an old version. 15:41.000 --> 15:46.000 And the test is defined in the ASCII doc markup. 15:46.000 --> 15:48.000 So, you can see here these are Dr. Tech. 15:48.000 --> 15:49.000 Test steps. 15:49.000 --> 15:53.000 What we're doing is we're telling it to do exactly what we tell the users to do. 15:53.000 --> 15:58.000 We're saying to run this Docker compose file, 15:58.000 --> 15:59.000 wait a bit. 15:59.000 --> 16:02.000 And this is important because this is a real test. 16:02.000 --> 16:03.000 So, sometimes they're flaky. 16:03.000 --> 16:08.000 You need to wait for Docker to start before Red Panda console is available. 16:08.000 --> 16:10.000 So, we tell it to wait. 16:10.000 --> 16:12.000 And then we tell it to do. 16:12.000 --> 16:14.000 All the things we tell the users to do check the links 16:14.000 --> 16:16.000 so that it will save the screenshots. 16:16.000 --> 16:20.000 It's going to check whether or not there's a difference between the current version 16:20.000 --> 16:22.000 and the screenshot we have here. 16:22.000 --> 16:26.000 And if there's a difference between the new one that is about to generate. 16:26.000 --> 16:30.000 So, I'm just going to run this. 16:34.000 --> 16:38.000 And while that's running, I'm hoping it's going to work. 16:38.000 --> 16:40.000 And I'm just going to explain how this will work. 16:40.000 --> 16:42.000 So, we've got a package JSON here that's set up. 16:42.000 --> 16:45.000 So, we've set it up to run specific test depending on the script you're running. 16:45.000 --> 16:48.000 So, I've just run the test console doc script, 16:48.000 --> 16:52.000 and this is going to just point Dr. Tech Dev at my quick start for Red Panda console. 16:52.000 --> 16:56.000 We've also got this built into our CI pipeline. 16:56.000 --> 16:59.000 So, we've got test docs.yamel. 16:59.000 --> 17:04.000 And we've set this up so that we can trigger it from repository dispatch. 17:04.000 --> 17:08.000 So, if there's a new tag in the Red Panda console source code, 17:08.000 --> 17:12.000 we can run our tests on this quick start to make sure that nothing broke 17:12.000 --> 17:14.000 in the latest release. 17:14.000 --> 17:17.000 And then we can also just run it on every pull request. 17:17.000 --> 17:19.000 So, if there's a pull request made, 17:19.000 --> 17:21.000 it makes changes to the Red Panda console docs. 17:21.000 --> 17:23.000 We'll run these tests, 17:23.000 --> 17:27.000 and then you'll get the test output in the pull request. 17:27.000 --> 17:29.000 Cool. 17:29.000 --> 17:31.000 So, it's running, which is good. 17:31.000 --> 17:33.000 Oh, no, it's got errors. 17:33.000 --> 17:39.000 So, there's some errors here because of the internet connection. 17:39.000 --> 17:43.000 So, what I'm going to do is just tether and try this again. 17:47.000 --> 17:55.000 Okay, how long is the time out normally? 17:55.000 --> 17:59.000 I've got it set to like 30 seconds at the moment, 17:59.000 --> 18:03.000 and we will try this one more time, 18:03.000 --> 18:05.000 and if I'm going to just increase the time out, 18:05.000 --> 18:09.000 because it is just networking for me. 18:09.000 --> 18:13.000 Because what it's doing on the back end is it's just, 18:13.000 --> 18:15.000 it's pulling all the documentaries down, 18:15.000 --> 18:17.000 and it's going to try and open 18:17.000 --> 18:19.000 the local Red Panda console instance, 18:19.000 --> 18:21.000 but it's not going to be able to do that if, 18:21.000 --> 18:23.000 like, Docker doesn't work. 18:27.000 --> 18:29.000 Well, while we're rating, 18:29.000 --> 18:31.000 should we ask for any questions? 18:31.000 --> 18:33.000 Yeah, good. 18:33.000 --> 18:34.000 Actually, why not? 18:34.000 --> 18:35.000 Normally, this would be at the end, 18:35.000 --> 18:37.000 but while we're waiting for Docker, 18:37.000 --> 18:39.000 and the network connection to do what it should. 18:39.000 --> 18:41.000 Any questions? 18:41.000 --> 18:43.000 Yes. 18:43.000 --> 18:47.000 Have you ever used this new test changes 18:47.000 --> 18:49.000 in your relationship to make a snapshot 18:49.000 --> 18:53.000 of what you're interested in changing 18:53.000 --> 18:55.000 or how you're talking about it? 18:55.000 --> 18:57.000 Uh, us two of me. 18:57.000 --> 19:01.000 I'm, so, right now, um, 19:01.000 --> 19:02.000 I'm. 19:02.000 --> 19:03.000 Oh, yes. 19:03.000 --> 19:05.000 Have we actually used this to, 19:05.000 --> 19:07.000 to test screenshots, 19:07.000 --> 19:09.000 and to do a screenshot change in our documentation? 19:09.000 --> 19:11.000 No, just test, just test, 19:11.000 --> 19:13.000 just test if you look at the location of this, 19:13.000 --> 19:15.000 but when you ever change, 19:15.000 --> 19:17.000 when you're the present change, 19:17.000 --> 19:19.000 so, putting a breath, 19:19.000 --> 19:21.000 to visualize exactly what this, 19:23.000 --> 19:27.000 don't even do some change change in the principle of the. 19:29.000 --> 19:31.000 Oh, um, 19:31.000 --> 19:33.000 that's going to be helpful. 19:33.000 --> 19:34.000 So, I think, 19:34.000 --> 19:36.000 um, what you're saying is like, 19:36.000 --> 19:38.000 how do you know if the documentation change 19:38.000 --> 19:40.000 compared to what the test says it should do? 19:40.000 --> 19:42.000 And I think the idea is just, 19:42.000 --> 19:44.000 you write the test to mirror 19:44.000 --> 19:46.000 exactly what your documenting. 19:46.000 --> 19:48.000 Uh, so, for that, 19:48.000 --> 19:50.000 you need an environment that's set up 19:50.000 --> 19:52.000 that's kind of going to be similar to what the user has, 19:52.000 --> 19:55.000 and then you have to run through the steps exactly the same way the user does. 19:55.000 --> 19:56.000 So, 19:56.000 --> 19:58.000 talk detective supports things like CLI commands, 19:58.000 --> 20:00.000 as you can check the output of them. 20:00.000 --> 20:01.000 You can save them, 20:01.000 --> 20:04.000 and then use the output within your docs. 20:04.000 --> 20:06.000 So, then if the test runs 20:06.000 --> 20:08.000 and the output changes automatically, 20:08.000 --> 20:12.000 or doc gets updated with the output of the new version. 20:12.000 --> 20:14.000 And it's similar to what we do here with the screenshot. 20:14.000 --> 20:17.000 So, when we take a screenshot, 20:17.000 --> 20:20.000 we save it to a specific location, 20:20.000 --> 20:21.000 um, 20:21.000 --> 20:23.000 and the test does the same thing. 20:23.000 --> 20:24.000 It saves it to the same location. 20:24.000 --> 20:25.000 So, it overrides. 20:25.000 --> 20:27.000 And so, here, 20:27.000 --> 20:29.000 the image will be updated in the doc, 20:29.000 --> 20:30.000 and that's automatic. 20:30.000 --> 20:32.000 So, all you need to do is just push your changes to GitHub, 20:32.000 --> 20:34.000 or have your CI pipeline, 20:35.000 --> 20:37.000 push the changes as a poor request, 20:37.000 --> 20:40.000 or just write to the branch. 20:40.000 --> 20:42.000 But that has completed, 20:42.000 --> 20:44.000 and you can see here that the version's changed, 20:44.000 --> 20:45.000 because it picked up, 20:45.000 --> 20:47.000 there's a new version of a panda, 20:47.000 --> 20:49.000 and so the screenshot changed with the new version. 20:49.000 --> 20:51.000 And then inside the doc, 20:51.000 --> 20:53.000 we just reference that screenshot. 20:53.000 --> 20:55.000 We just don't want to show it here, which is annoying. 20:55.000 --> 20:58.000 But we reference the same screenshot. 20:58.000 --> 21:01.000 And then, like Ariel showed, 21:01.000 --> 21:02.000 you get the run down, 21:02.000 --> 21:05.000 and you can see if any of your steps failed. 21:05.000 --> 21:07.000 And it's going to show me that that's that failed, 21:07.000 --> 21:09.000 because the screenshot was so different, 21:09.000 --> 21:11.000 and compared to the previous version of it. 21:11.000 --> 21:13.000 So, that's what you can use in your CI pipeline, 21:13.000 --> 21:14.000 and you can say, 21:14.000 --> 21:15.000 if it does fail, 21:15.000 --> 21:16.000 then do this, 21:16.000 --> 21:17.000 create a GitHub issue, 21:17.000 --> 21:20.000 or create a GitHub request. 21:20.000 --> 21:22.000 And that's another thing that's great about doc, 21:22.000 --> 21:25.000 to take a bit of has a GitHub action that you can use. 21:25.000 --> 21:26.000 So, that's what we're using here. 21:26.000 --> 21:29.000 It's called the doc detective GitHub action V1, 21:29.000 --> 21:33.000 and that runs everything in a doc environment for you. 21:37.000 --> 21:39.000 Let's go back to the slides. 21:45.000 --> 21:47.000 As with everything, 21:47.000 --> 21:50.000 bear in mind that your test actions 21:50.000 --> 21:52.000 are in fact real actions, 21:52.000 --> 21:55.000 and you are working on your documentation, 21:55.000 --> 21:59.000 so make sure you are developing your tests well. 21:59.000 --> 22:02.000 This is a part of the writing process. 22:02.000 --> 22:05.000 It is going to create artifacts, 22:05.000 --> 22:07.000 it is going to create logs, 22:07.000 --> 22:09.000 make sure you clean them up, 22:09.000 --> 22:11.000 practice good documentation hygiene, 22:11.000 --> 22:14.000 and make sure to test against your data. 22:14.000 --> 22:18.000 You can test against theoretical data as much as you want, 22:18.000 --> 22:20.000 but ultimately, 22:20.000 --> 22:23.000 you are doing this for your own data, 22:23.000 --> 22:28.000 and you don't know what will happen if you use synthetic data, 22:28.000 --> 22:30.000 implemented live, 22:30.000 --> 22:32.000 and then you find out that your synthetic data 22:32.000 --> 22:36.000 was not quite what you needed to do. 22:36.000 --> 22:40.000 But these are all part of the documentation process, 22:40.000 --> 22:43.000 and this is a way that you can also integrate best practices 22:43.000 --> 22:46.000 and make sure that everyone is aligned. 22:47.000 --> 22:50.000 Okay, cool. 22:50.000 --> 22:52.000 So yeah, these are the resources. 22:52.000 --> 22:54.000 Docs' test is a strategy, 22:54.000 --> 22:55.000 like we said, 22:55.000 --> 22:57.000 there is a blog post about it, 22:57.000 --> 22:58.000 the money silver row. 22:58.000 --> 23:00.000 He is also the maintainer of Dr. Techive, 23:00.000 --> 23:02.000 so you can go there to see the docs, 23:02.000 --> 23:04.000 and there is an active discord channel. 23:04.000 --> 23:05.000 So if you've got questions, 23:05.000 --> 23:07.000 or we just want to try it out, 23:07.000 --> 23:08.000 we're both in there, 23:08.000 --> 23:10.000 and so is money. 23:10.000 --> 23:12.000 So yeah, go ahead and try that. 23:12.000 --> 23:13.000 And that is it. 23:13.000 --> 23:15.000 Thank you, everyone. 23:16.000 --> 23:18.000 Thank you. 23:36.000 --> 23:38.000 Is it only web tools, 23:38.000 --> 23:41.000 and can you evaluate source code? 23:41.000 --> 23:42.000 Yeah. 23:43.000 --> 23:48.000 So yeah, so Dr. Techive supports CLI input. 23:48.000 --> 23:50.000 So you can test CLI commands, 23:50.000 --> 23:52.000 which also means that you can run scripts. 23:52.000 --> 23:55.000 So part of the test that I just ran 23:55.000 --> 23:57.000 will run the scripts, 23:57.000 --> 24:00.000 the fetch the latest version of Red Panda, 24:00.000 --> 24:03.000 and then store those in environment variable, 24:03.000 --> 24:05.000 and that is the find here. 24:05.000 --> 24:06.000 So it says, 24:06.000 --> 24:09.000 Run show is the action in the step, 24:09.000 --> 24:12.000 and then we tell it to run this JavaScript file, 24:12.000 --> 24:16.000 and then we say to whatever is in the output of that script, 24:16.000 --> 24:18.000 store it in this environment variable, 24:18.000 --> 24:19.000 and this one. 24:19.000 --> 24:21.000 And then what we have is in our Docker compose file, 24:21.000 --> 24:23.000 we use those environment variables, 24:23.000 --> 24:24.000 so they get set, 24:24.000 --> 24:27.000 they get used when Docker spins up Red Panda, 24:27.000 --> 24:29.000 and yeah. 24:29.000 --> 24:30.000 So you can run scripts. 24:30.000 --> 24:32.000 Can you use S, 24:32.000 --> 24:34.000 to keep seeing more of that? 24:34.000 --> 24:36.000 Yeah, I think so. 24:36.000 --> 24:38.000 I think because it supports any kind of scripting, 24:38.000 --> 24:39.000 I've never done it, 24:39.000 --> 24:40.000 but I would assume so. 24:40.000 --> 24:44.000 Yeah, so sorry, 24:44.000 --> 24:45.000 the question was, 24:45.000 --> 24:47.000 does it support ASCII cinema, 24:47.000 --> 24:49.000 and I believe so. 24:49.000 --> 24:51.000 And there was a question over there? 24:51.000 --> 24:52.000 Yeah. 24:52.000 --> 24:53.000 So kind of piggybacking out with that. 24:53.000 --> 24:55.000 You mentioned you can make screenshots 24:55.000 --> 24:57.000 of your current test run. 24:57.000 --> 25:00.000 Is it also possible to catch the output of these commands steps, 25:00.000 --> 25:02.000 and then have them out in server file, 25:02.000 --> 25:05.000 to include in the documentation of background? 25:06.000 --> 25:07.000 I haven't done that yet, 25:07.000 --> 25:09.000 but I think you do that. 25:09.000 --> 25:10.000 It is possible. 25:10.000 --> 25:11.000 Yes. 25:11.000 --> 25:13.000 I don't think we don't currently store the output, 25:13.000 --> 25:15.000 but we check the output. 25:15.000 --> 25:16.000 So we'll say, 25:16.000 --> 25:18.000 as long as the output contains this string, 25:18.000 --> 25:21.000 then it's good if not then it's bad. 25:21.000 --> 25:22.000 The one thing I will say, 25:22.000 --> 25:25.000 because you also asked about CLI commands, 25:25.000 --> 25:27.000 that's something I'm testing right now. 25:27.000 --> 25:30.000 One of the issues I ran into is that 25:30.000 --> 25:33.000 one of our internal APIs is complicated enough 25:34.000 --> 25:37.000 that I'm having problems with the way 25:37.000 --> 25:39.000 Dr. Tettiff currently works. 25:39.000 --> 25:42.000 The maintainer is working on that for a future release, 25:42.000 --> 25:43.000 but in the meantime, 25:43.000 --> 25:46.000 the workaround is to actually call command line tools 25:46.000 --> 25:49.000 to do some checking and use that output. 25:49.000 --> 25:52.000 And I have access to all of that. 25:52.000 --> 25:53.000 Yeah. 25:53.000 --> 25:55.000 So I don't know if you can see that. 25:55.000 --> 25:57.000 But that's an example of output. 25:57.000 --> 26:00.000 So after running this command, 26:00.000 --> 26:04.000 the output should contain pandas of fabulous. 26:04.000 --> 26:05.000 And that's how it works. 26:09.000 --> 26:10.000 Fantastic. Thank you, everyone. 26:10.000 --> 26:11.000 Thank you. 26:30.000 --> 26:32.000 Thank you.