 Welcome to the Sheikot Africa screen shot updates project meeting, it's 25 April topics that I had on the list while we're waiting for our participants to arrive. DT and I were going to discuss automation ideas for screenshot updates and talk through different concepts and things. This is not the focus of the Sheikot Africa project at all, but it might align with it. We're going to identify it aligns with it because we're identifying screenshots in this project and aligns because we are updating the screenshots interactively. So we'll have to go through steps to reach the point where we can take the screenshot. So Aditya here's here's some conceptual model for me which was okay the documentation includes a screenshot right that is preceded by some some words explaining the screenshot or its contact and that you'd expect that. So that's that's how we do screenshots. However, what it that those words are not precise enough to tell a computer how to do it to how to how to duplicate that they and they can't be they naturally cannot be because we write for human beings. Not for we write for people not for machines right the documentation's purpose is not to satisfy a machine is to satisfy a person. So then the question is how do we represent. How would we represent those steps, the machine executable steps to reach the screenshot. There are some additional questions like how would we expressed that a portion of the screen is needed, not the whole screen, because in many of the examples in the screenshot sheet, we can see let's let's jump to one and take a look at it so here. It says that the health icons have changed so when I opened that page. We're going to see okay this one is the whole screen. So that one mechanically I could see how we could grab it. These individual pictures of the health icons are not the whole page. They are they are something different and in fact they might be better. Let's let's phrase this is another way. Some screenshots aren't screenshots at all some screenshots. A few of the screenshots are images in the Jenkins source code. So maybe those we just say hey that's not a screenshot at all it should just extract the image from the Jenkins source code that is used for partially sunny that's used for cloudy whatever that image is should be should be embedded here. If these may be up to date I'll have to look to be sure but so so that's the that's the idea then is okay how do we how do we get that information into an out into a machine into an automation system. Now back to the first question how would we represent machine executable steps. So Python's PI doc facility invites developers to write tests in the documentation and and they do that by by expressing the steps in a machine readable format. So that's one alternative another might be behavioral behavior driven development uses a encourages the creation of creation of a domain specific language, dedicated to the specific tasks, the specific product being tested, and the tasks in that product. So it might be things like let's see let's let's grab an example. And we could probably since Jenkins is Java we could use. Here we go. Let's let's take a look at an example right here we go. This one is a lot of fun because it shows exactly how to do. Here is the. Here is the description that they use to describe precisely. Oh, thank you very much for the ad describe precisely how to how to prepare how to prepare for and execute this. So that it's written in English English language adding an item to order I want to be able to add an item to a current order scenario describes what we're going to do before we start the test. I have not yet ordered anything as a pre pre condition then I go to the burgers category, select a cheese burger, have a new order and the order has one item in it so this is described and then it gives data that's used to describe it so there's a category in the category sandwiches I have the item a chicken sandwich price $9. And now we see as they take us through it how that how that gets implemented. And they really are creating a testing description language, which I think could also be a screenshot description language in this case is one idea of how this kind of thing has been done. Now I did you I've been talking a lot. Does any of this resonate for you or give you a sense of ways we might approach it. Yes, definitely. So I was not aware of the pie dock thing. Look into it. I have done some behavioral development development we did in the past and familiar with cucumber what exactly what you showed me. So good. Yeah, so that's something I'm familiar with and I never thought that it could be used for something like this. So that's some a new way to look at it and yeah that's something again I'll definitely look into when you talked about screenshot automation the first thing that came to my mind was actually those end to end testing libraries in the front end that we have. So, in front end like if you want to test your login page for example, it would just pin up an instance it will actually type in the login it will, you know, automatically type in the login credentials hit the login button. It will actually happen that way. So I thought if we have a part to actually go to the page where the screenshot is in the Jenkins deployment we can actually write an end to end test like an interactive test as you are mentioned that actually does that and there we can have that in and this is something hypothetical. I'm not sure how will you capture a particular section of the screen taking the screen is an easy task as you mentioned taking screenshot of the whole thing. But yeah we'll have to see how we can do a section of the screen and then that can be basically will be the updated screenshot and we can just update it. So that's one thing that I thought of. I've used Cypress and all the open source tools that are there Cypress.io in the past and I think we can give it a try as well how easy or difficult to write something. And Cypress.io is an example of end to end test automation right with a web browser is that correct I'm not experienced with Cypress. I'm I had used Selenium once in the past Selenium. And Cypress is conceptually something similar right where it's, it's actually driving a web browser and while driving the word the web browser. I know at least Selenium has the facility to take a picture at the end to show people what something failed as so I think it's that kind of thing. Yes, Mark you're right. Now, there was another one that I had heard of called Zikuli. That is, it is, is, if I remember correctly isn't a test framework that actually compares screenshots. So it's it clearly must be taking screenshots because it's comparing them. It's, it's a yet another way of considering that same thing I think. Let me look to be sure is it did I spell it correctly. Test automation. Web test automation tooling. Nope. Oh, I spelled it wrong. Okay. Spelled with an S not an S is the Zikuli. Here it is. Okay. Zikuli is a is the same kind of thing only it. It uses very much if I understand correctly it absolutely uses pictures, and it compares images so it's asserting the context contents of images. So it's quite different from Cypress where they're, I think they're inserting a certain things inside the browser. Right there they're asserting is the DOM correct and is the is the is the the object model inside the browser correct. And that has all sorts of strengths and power to it. Good. Okay. And then, yeah, certainly selenium. And, oh, there was a behavior driven thing around that. Oh, Ruby. What is it called the Ruby version there's a Ruby thing that does Brian Merrick did it just a minute and a long time. Brian Merrick Ruby web test automation. I don't remember the name of it. I hadn't heard of that one. Ruby Ruby web testing framework. I should remember this. I apologize that I don't that's really kind of sad. Not a copy of water. That's the one that I had seen before. Okay, so water. And you said Sahi or Sati. It's Sahi. But I haven't used it. It's just something that came up in a website sometime back. Ah, okay. All right. So, so it's Sahi is another is test automation for for desktop apps. Yeah. Okay, all right. Okay. Okay, I think probably not something that we end up using. Well, again, it does play back on browsers. And so that that could let us capture the screenshots. Good. So, so those were the things that were on my mind as possible. I'm sure that Gavin Morgan has other ideas and his, he's certainly got a lot more experience in this area than I do, but, but for me the, the, the question of approach how do we, how do we represent the machine executable steps is the is the bigger challenge, right? It, if we represented them as, as you said, as interactive test automation, that gives us interactive tests that are now regular being run and could be used in more places than just documentation generation. Right. So the benefit of that technique usable in other locations, not just test automation. There's a screenshot automation. There's a, there's this, the acceptance test harness for Jenkins that does something like this, but I don't think it's using any of those frameworks. Just a minute, let's take a look at it, because it might be that we could conceivably. So it does it using Selenium, right? Let's see, where is it? End-to-end test suite for Jenkins Automation Server and Plugins, tests controlling Jenkins under test through the UI and REST APIs. So it has the benefit that it knows about Jenkins REST APIs and some of those REST APIs could be much more helpful to do initial configuration than trying to drive through a web browser. So if we need, if we need certain objects created, it's probably much faster and easier and more reliable to do them through a REST API than it is through a web browser. So, so let me put a link to this one. And where is it that it says it uses Selenium? I just, oh yes, here it is. So this might be another, another approach where we say, hey, we want to get two gains from this is we'll get a few more tests for the acceptance test harness. And these things happen also as a side effect to generate screenshots that we can use. And now, I don't see any mention here of, oh, debugging tests in a container. Does it, I think it may. No, it doesn't show us how to grab. Oh, it shows how to run the debugger. So you don't have to have to be and it assumes you're looking at Firefox locally. So it's not attempting to grab you a screenshot from somewhere else. Let me make a note of that. Okay, so Jenkins acceptance harness uses Selenium for end to end testing. So, so for me that might lobby that we should consider Selenium, if only because we've got people who have created a significant body of tests and Jenkins acceptance test harness. And if you look at the source code, the tests, there's quite a collection of tests. All right, so let's see for instance, well, what have we got here maybe the best acceptance. You know, there aren't a lot here. I thought we had a bunch that were being run by, by, by others maybe I'm there on a different branch or I need to have a conversation with people to be sure I understand. But it's for me acceptance test harness might be a place that we would consider. Hey, might be an effective way to do it because it already exists and we've got people with skills, and it's using Selenium as a known technology. I agree with you on that part. Selenium has a community support right. Right. All right, so those were, those were the kinds of ideas I had anything else you wanted to add before we close our meeting Aditya? Nothing else that comes to mind right now, but I'll go through these and probably you can have another discussion next time. Great. Thank you. Thanks very much. Thanks for being here today. I'll save a copy of this recording so that it's available and get all the other recordings uploaded that I'm supposed to have uploaded. Thanks again, Aditya. Thank you. Bye bye.