So it gives me great pleasure to welcome Fergus Cooper, Dr Fergus Cooper from the Oxford Research Software Engineering Group. They have their own website. You can see UWW rc talks to UK. They're also on GitHub with the username Oxford RC, which all one word capital, our capital R Capital s capital.
Today, Fergus is going to tell us three examples this time how to do automated testing examples, in this case with Python, but more more importantly, connecting that all up to version control on GitHub and continuous integration. So Fergus did his doctorate in the Mathematical Institute here in Oxford through one of the doctoral training centres.
Siddiqui's Syst. Biol., from 2013 to 2018 and then set up helped set up with Dave Gavigan and Martin Robinson, the very Oxford research software engineering group that he is in now. So with that, I'd like to hand over to Fergus. Well, thank you very much, Garrett. It's a real pleasure to be here.
And yep, as as Garrett said, I've sort of stepped in at the last minute, so I've put together some material on how to do continuous integration, how to link that up to, in this case, a small Python project that I've just set up in the last couple of days and really on good start off with a very short presentation that just goes through a little bit of a reminder.
And the people who might be what half of the previous talk, why we might be interested in automating the tests for our software, why that might be a good thing. And then going through a quick overview of what I'm going to be talking about and then the risk of tempting fate at the remainder of the talk is going to be all life examples. Well, I'm going to take the Python project that I've set up on GitHub, and I'm going to run through all of the steps to do a number of things.
That's going to include setting up automated testing in a number of different settings. And then. Linking that up with a number of third party tools that can. Further help to to add some robustness and some confidence in the software that you've written and really the benefit is that all of this will be being run automatically whenever you make changes to the software. And so it's just one less thing for you to have to think about. You never have to run the tests locally on your machine.
It will all be done in the cloud and bonuses or completely free as well. So without further ado, I'm just going to start off with a very quickly and overview of the recent software engineering group never going to pass up the opportunity for quick, quick plug. So what do we do? Well, we help enable your research by by developing bespoke software for you.
And we can facilitate your research by improving the quality of the software that you're writing and helping to improve software engineering best practises across academia in general. Doris already mentioned our website where at RC Dot Oxtail that got up. And if you go on to there, you can fill in a quick form if you are interested in working with us.
Great, so automated testing, so this is just a really a very, very quick sort of two minute recap from things that Graham was talking about last time. And really the purpose of an automated testing is ensuring that as you develop the project, as you work on it week after week, month after month that it stays correct. You know, it's extremely easy when you've written some functionality, perhaps some quite complicated functions that may be a little bit of time later you go back,
you make some changes, you think, OK, I've got a better way of doing something. Maybe I should. Maybe this function should take three parameters rather than two. And then maybe you forget that some other piece of functionality in your code might rely on the old assumptions that you've made. And when you make that change a little bit later, you say that they break something and maybe that thing that you've suddenly broken isn't something that you often use.
Maybe it's not something that gets run a whole bunch. And then maybe later on, maybe a few months later, even you realise that the functionality that you thought you could rely on. Doesn't work anymore. And so one thing that's really critical is to automate this testing of the software so that over time you are keeping in the position where every aspect of the software is working.
Now, this might sound as though it's, you know, an onerous thing to do, but really, if you get set up with the tools that we're going to be talking about today, you get those tools set up early and use them consistently. It will actually save you a huge amount of time. But just to take a step back. First of all, the reasons that we need to do this sort of automated testing.
Number one, correctness, we need to make sure that if we're writing code, whether it's a short script to do some data analysis or whether it's a large simulation framework that's going to be doing a huge amount of kind of number crunching. You need to make sure that that code is doing what you think it's doing. We all know we've all come across little bugs that we've written in in codes, and quite often those bugs aren't necessarily a big deal.
They might just change a little bit. They might not actually change the results at all. But it's important to have confidence in the code that you've written that is true for you. You need to know that the code that you've written, the results that you've got are not going to just fall out from underneath you and you realise that that was a critical bug in the software that you've written.
The people who are peer reviewing the paper that you're writing will once have confidence that the code that you've written is doing what you've told them that it's doing. And more widely that we'll get on to later, the kind of wider academic community requires you to have confidence in what your software is doing. I'll talk a little bit about that on the next slide. But the next point is reproducibility.
If you've just got some software and it's sitting in a directory, maybe it's not even under version control. Maybe you've got two scripts that take some data that you've generated and turns that data into a nice plot and that floats is Figure 3A on the paper that you're writing.
We've probably all been in the situation where we get a paper back from peer review and and you need to make a few changes, they asked you maybe to add in another graph or change something or do something, even perhaps a cosmetic tweak to the graph that you've produced. If you got the tool set up appropriately, then it's going to be absolutely trivial to go back to the version of the software that you used to.
Create that growth if you're testing is in place and has been for ages, you know that when you go back to that software version that you used to produce that graph, it's going to work, it's going to work exactly the same as it worked when you actually created it in the first place. And in this kind of way, reproducibility becomes trivial if you get the tool set up early and use them all the way through. So we'll talk a little bit about that as well, but also visibility.
If you're automating your testing, you can signpost that to people when they visit your GitHub page. When they look at your software, when they look at the website that details how to use your software, you can show them, Hey, look, we're testing this against all the different Python versions. We're testing it on multiple different operating systems. We have code coverage. We have X, Y and Z. If you can just show that to people, but that is something that you're doing.
They can immediately say, OK, this person really looks as though they know what they're doing, they're testing it and all of these different ways. And I can be sure that if I'm using the software, it's I'm going to want to try and reproduce a piece of analysis that they've done. I'm probably not wasting my time. They're probably correct.
And having that visibility is going to make it a lot easier for you to disseminate your work a lot easier for, say, peer reviewers on your publications to believe the code that you've written is as up to scratch and a lot easier to to get your code out there for other people to use.
So why are you really is this important? I mean, one thing that we've seen over the last number of months specifically in this this time of COVID, we've seen that there is a huge amount of scrutiny now on academic code. And you know, there are some specific examples I'm thinking of this. For instance, the the software that Neil Ferguson wrote that that was the famous paper that that really initiated the lockdown. That code has since been made available on GitHub and rightly or wrongly.
There has been a huge amount of criticism on the GitHub if you've gone since GitHub now and looked in the issues for that piece of software. There are a very large number of very critical comments some of them warranted, some of them perhaps not warranted, but particularly now there is a huge amount of scrutiny and. You are going to be able to insulate yourself from all of that if you are following the best practises, if your code is well tested, well documented.
It's not going to be possible for people to be as critical about your software as perhaps they can be about software that isn't well implemented, well-designed, well tested. The good thing, though, is that there are more tools than ever to help you, so this is not an onerous thing to do if you get set up properly. And the purpose of this talk today is hopefully to demonstrate to you just how easy it can be to get some measure of continuous integration set up.
Once you've got some measure of it set up, you can incrementally add things. You can incrementally make it more complicated. You can do more and more and more things. But really, the first hurdle is getting something set up. Once you've got something sets off, it's dead easy to then continue and carry on going. And today we're going to look at a number of those tools. So what is continuous integration? This is a phrase that I've been using a lot already, and I haven't really defined it.
I'm not really going to define it either, but you're going to see some examples of it. But essentially, we can think of it, at least for the purposes of today's talk. It allows you to automate the testing of your code and much more. It's something that can interface with often many third party services that help make your life easier. It can run, usually for free in the cloud. This is not software that you ever have to install on your machine.
This will be running in the cloud for free, and it allows you to test your software on multiple operating systems, multiple software versions, and it allows you to do that easily. There are a number of different services available that provide this kind of ability. One is try to see what is up there. And the one we're going to be focussing on today is GitHub actions and GitHub actions is a system that's built directly into getup up.
So again, you don't need to go out to a different service for this. And GitHub actions in particular is very generous about the amount of compute resources that you're given. And what I mean by that is what we're going to be setting up is something that essentially allows you to use.
Virtual machines owned by GitHub in the cloud to do some work, and in this case, the work is primarily going to be testing your software, but essentially you're opening up a virtual machine that has two or seven gigabytes of RAM and can run for up to six hours, and you can have many, many of those happening in parallel. And really, that's more than sufficient for pretty much anyone's testing needs in terms of a piece of open source software.
So it really is very generous. And in this talk, I'm going to give you a very quick tour of a simple Python project that I've set up. We're going to go through live setting up automated testing that's going to test all Python project against multiple different versions of Python. Then we're going to set up automated testing on multiple operating systems. So we're going to want to check that this still works on Windows, on macOS and on Linux.
Then we're going to add in coverage testing, and that's going to be using third party service called code cuts. Again, this is a free service if your software is open source. We're going to, depending on time, get on to automated documentation generation using read the text audio and again, at this time, I'll show you something about something called better code up again. That said, party service that could be integrated for free on open source projects.
And that's the end of the presentation. So what I'm going to do now is get straight into showing you the Python project. So the Python project is available on the Oxford RC GitHub, so you're more than welcome to navigate to this. There'll be some things happening live that you'll be able to look at yourself on your own machines if you'd like to do that. So if you would, you can head over to GitHub dot com slash Oxford RC slash site demo.
It's completely open. So you'll be able to see things as they're happening during the course of the talk. So in this project, I'm just going to show a few things. We have a. Python package in this case, it's made the same as the as the name of the project, all of the functionality of which there is very little is in this final functionality baked pie. So in here, I've just got two small functions, one function that is going to take a name and it's going to present a greeting.
And one is a function that tells me, Well, I've written this function. It's just the first thing that came to my head. It's going to take a bunch of arguments and it's going to return the minimum of all of the arguments in there. That happens to be real numbers that have an artificial function. Not sure why you'd want to do that in particular, but I needed a function to test and then.
In this directory as well, we have some tests, so we have a test functionality pie file that uses the unit test framework. If you're familiar with unit test or not doesn't really matter. The point is that there is a command I can type from the terminal that will run these unit tests.
And in this case, I'm going to test some basic things that if I use the Graetz method, it will return the greeting I'm expecting it to, and that if I use the minimum method, it will return the number that I'm expecting it to return. So it's all relatively straightforward. And now what I'm going to do is head over to my ID. I'm using Python today and. Here we can see exactly the same code. So here I've got the functionality two functions, one called greets and one called minimum.
And if I open up my terminal, I can run these unit tests by typing places and flush them. Units test, if I run, that's we'll see that it ran two tests. I open up the test will see the two tests that it ran on the test greeting and test minimum. And in fact, if I put a Dash V on the end, we'll get a slightly more verbose output from unit test. And we can see here that it's run test rating, which has passed and that's run test minimum, which has also passed.
So that was running locally on my machine. And what I want to do now is run that on GitHub actions. So what I'm going to do is go back to my web browser and back to the. See, I am a repository. Along the top here we have, as you're probably familiar, a number of tops and one of them is actions, actions should be enabled by default if you've created a GetUp repository since GitHub actions existed.
If you don't see an action tab on your GitHub repository, then you'll just need to head into settings. And then to actions. And then make sure that this setting is enabled, enable local and set policy actions for this repository. Once you enable that, you'll see the Actions tab. If you don't see it already and they're not actions, you can see some history in here because I've obviously been messing around with this,
making sure that this is hopefully going to work for this talk. But if you've not got any action set up yet. What you'll actually see when you come into this page is something that looks like this, and this allows you to set up some basic starter workflows, and that's what we're going to do now. So what I'm going to try and do is set up from scratch a workflow that's going to run the unit tests that I've just shown you running locally,
but testing them on multiple Python versions. So I quite like this one, the Python packages. This is a test workflow that's going to create and test a Python package on multiple Python versions. So I'm just going to scan has set up this workflow. And this is going to actually create a file that will be added to your repository itself in a particular directory and a directory called Dot GitHub slash workflows.
And this is going to create a file with a Yamal syntax that's relatively easy to to see what's going on. So in this file, which is just being created for me, there are some key features there's firstly a block up here that tells you when this action is going to be run.
So the really important thing, particularly if you're the only person developing and you're just using gets as essentially a way of saving your files and you just have one branch, then the important thing is that this is going to be triggered every time there is a push to the master branch. It will also be triggered if there's a pool of request onto the master branch as well.
Then it's going to run a job and the job is going to build something it's going to run on in this case happened to latest. This will run on at the moment open to a floor that will probably be updated to take law at some point in the coming months. And this particular one is going to be a matrix run again, this be generated automatically, so you'll see this if you press the same button on your Python repository.
We're going to be testing against all of the currently supported Python versions, which is 3.5 three to three point eight, and then it's going to do a number of steps. Some of these we're going to have to edit, but you'll see that the steps here. The first. Step is to check out the code. The second step is to set up a Python version, and the syntax here is that it's going to get the Python version from this matrix of options.
So this will be replaced at runtime with either three point five, six, seven or eight. Then we're going to install dependencies. Now this is going to look slightly different to the default, but my particular repository, because in my particular repository, instead of our requirements stop text, I should be able to just hit.
Install and then dot, it will just install itself. And I've listed the dependencies in my set up that I. And we're not going to need playtest might set up the play contains the necessary dependencies, so this install dependencies is going to first of all. Upgrade pick, then that's going to install Flake eight two, which will see in a minutes, then it's going to install my Python project.
The next step in the workflow is it's going to do something with like eight now if it's not coming across at the fourth, like eight is just a linzer that's going to check that your Python code is up to certain standards in terms of how it's laid out. And it will also act in a way as a static analysis tool, and it will try and pick up some common errors that you might have in your package as well with running play dates.
I'm just going to change this slightly because I want it to treat warnings as errors. I don't want to ignore these things I want, but if there are errors, I want to know about it. So this part is going to run flat out against my software and check that there are no problems with it as far as black AIDS is concerned. And then it says here test with blood test will actually I'm using unit test rather than test.
So I'm just going to change this. And instead of I test, I'm going to do Python, Dash and unit test, and then I'll make up the base as well. So hopefully with any luck, that's all of the changes that I need to make and I can start to commit. So I'm going to add a new workflow. Christine, you commit that I'm actually I'm going to change this name to probably. And then. Three point five. The Python versions. Something like that.
Steinmetz has a new workflow and then I'm going to commit this new file. This is going to commit straight to the master branch. This file now exists in the repository, and if you were to go to this repository now, you'd see that this file exists. Now the magic is if I click over onto the actions, you'll see that there is something happening.
I can click on this. And I can see that now there are four bills happening, so what has just occurred is that gets her behind the scenes has spun up for virtual machines and each one of those is going to be running some stuff. And mostly what you're seeing here is the real failing, which is actually completely intended. So you can look into each of these. Runs and inspect exactly where each of them sailed.
So just to recap, what's happened is a virtual machine is being spun up, running a boom to wait for. In this case, it has checked out my repository locally. It has set up a Python three point eight in this case, three point seventy six and five on the other ones. It has installed the dependencies necessary to my project. And then it's attempted to Linux with like eight, and it's decided that there's something it doesn't like. OK, so what has happened here? We look at this error.
So here we're saying apparently there's something over indented on line 22. All functionality that pie. Okay. Well, I actually knew that that was because I deliberately did that. So that's the state would fail if I go into functionality that I and then look at Line twenty two. Oh, okay, yes, I see this written statement is actually indented twice rather than once, so I can save this change. I'll just go to my guess thing.
I'll actually want to just start that change quickly. Will these latest changes the workflow that was committed directly to get up and just change? So if I create a committee here who speaks in dense. Commit that change and push it. Like, go back to the GitHub repository now. I've now hopefully fixed that. If I go back to the Actions tab, you'll see that it's picked up the fact that I've pushed a new commit to master it,
spun up the floor virtual machines again. And now if I look into this build three point eight. With any luck, that particular area will no longer be apparent. So we'll we'll see. This is the benefit of doing it life. I don't know what this is going to work or not. Magic has. And I'm just going to wait four minutes for the other ones to finish. Oh, OK. We've got a failure on three point five.
And because it's failed on three point five, three point six and seven will probably bail out partway through. So we'll see here that now this this links with vacates rather than produced no errors. The next step, which is actually running the unit tests that has in this case succeeded. But we have a failure on three point five, so let's go and investigate that links with Flight eight. OK. It says, OK, OK, this is interesting. So we've got a syntax error on line nine of functionality.
Top pie. OK, so let's go back in and look at functionality. The Pie Line nine. Was it my mom? No, it was line 11. OK, I guess so. Line 11 has a syntax error, and this is now one of the first things that that's really useful about running this continuous integration in the cloud because I'm able to run on multiple Python versions. I get more information than if I was just running it on my laptop. If I down here in the terminal, check the Python version that I'm running.
I'm running 3.8 because I'm on a new version of Open two, so I've got a really, really recent version of Python. I probably want if I'm disseminating my Python project widely, I'm going to want that to work for as many people as possible. That's why I want to check against Python three point five, six, seven and eight. And in this case, Python 3.5. It doesn't work on Python 3.5. And the reason it doesn't work on Python three point five is it's artificial.
In this case, I'm using an f string, which if you're familiar with Python, you might know about. That was a feature introduced in Python three point six. So actually, I knew that this was going to fail on three point five, but I wanted to highlight the point that's allowing. You to run your code against every Python version that supported means that you can get as much information as as you can about whether it's going to work for the widest possible number of people.
There are still going to be people out there using Python 3.5. So in this case, we could make two options. We could either just say, sorry, Python three point six and above only if we really want to use this feature, or alternatively, we can just change this to something else we could do. Hello plus name in this case. So for the purpose of getting this working on Python 3.5, I'm going to go ahead and make that change. So I'll create a new commits to make it work on Python.
Three point five. Commit that and push it. And then if we go back. Two actions. Might just take a second. There we go. That's picked up this change again. It spun up its four different. Virtual machines, and with any luck this time this will pass. I'm going to have a look in on three point five. Just installing the dependencies. And in this case, great, it's now past. We've got green techs everywhere. Just waiting for three point six to finish off. And 3.6 as finished as well, great.
So this is nice if I now go back to the actions I can see here. That we now have a green tick against this workflow. If I click on the something someone, I am sorry. Unfortunately, the the Zoom thing is in the way as well, which is slightly irritating, so I make it work on Python 3.5. I can now create this status badge. So if I create the status badge, it hasn't updated itself yet. It is now passing.
But I can copy this markdown badge if I wanted to, and I could put that in the Read Me Dot, M.D. for this project, like an edit this file. At the top here, I can now put in this badge. I can probably see a preview here in my I.D., I've got this package Python package is passing. If I now just quickly alter this comment. It's unfortunate that go back now to my colleague Tamou GitHub repository. Now we can see in the. GitHub repository home page.
Now that that status badge has has appeared now, in this case, what's happening, it will take it usually usually takes it a few minutes. GitHub does some some caching with with these patches, so it might just take it a few minutes for this to pick up the fact that it's changed to being a pass. But nonetheless, at some point in the next few minutes, I would expect this to turn into a green patch.
And now, when people come to your GitHub repository, they're going to see that the build is passing well. At the moment, I'll say it's failing, but that's that's not true. They'll see that this build is passing, and that'll give them some confidence that that's that your software is being checked, which is good. OK, great. So now, as I said, that the the workflow file is just a. File that's committed to the repository, so if I go to GitHub slash workflows, there's Python versions.
Doc Yamal is just now source code. In my project. I can do whatever I like. I can edit it from here and commit those changes, and that will just get pushed through. That's that's no problem at all. But what if I wanted to now test on multiple different operating system versions? Well, that's no problem at all. So let's just copy and paste this file and. Create a new YAML file called OS versions of operating system versions.
And then instead of calling this Python package, I'll call this. When those. Mac, OS and Linux. Again, this is going to be run on pushes to master instead of runs on open to latest, I can use this matrix notation. I can change. Matrix Dot Python version two Matrix Dots OS and then change this Python version here to OS and GitHub actions allows us to run on Linux, Windows and Mac OS so I can change this now to happen to your latest Mac OS latest and Windows latest.
There are other options as well. If you want to use a different version of an operating system, there are a small number of options that you can pick from. But now, instead of Python version, we can just do fixed by compression, so in this case, perhaps 3.8 the most recent and will change this as well to three point eight. So just to recap, this is exactly the same script as it was before we're going to run Flake eight and we're going to run the unit tests,
but this time we're going to be running them on. Multiple different operating systems, and that's going to be picked up using this matrix notation. So I'll save this file. Go over and commit it. Push it. So if I go back now to the repository and look under the Actions tab, then it might just take it a second to pick up. We now see that we have multiple things happening on the left hand side, so if I look at workplace and multiple hours now.
This is the one that still checking against multiple different Python versions, that's fine if I get on the other one, that's less active at the moment. I'm building on it. Buntu latest Mac OS latest Windows latest. And so if we have a look at, for instance, the Mac OS, which has just asked for some reason that was the quickest. It's sets up this job. And you can see and here we are on Mac OS 10.0 15.5 don't know anything about that.
What version that that means it's running on, but it's created a virtual machine that's running Mac OS, and it's done all of the things says install the dependencies limited with like eight to run the unit tests and we've got a green tick. Great. And that's passed on everything, and that's probably one more thing still running on here.
No, it's all passed now. So if I go back to the Actions tab, we can see that we have now got two parallel workflows, both passing one that's checking on every Python version and one that's checking on the three common operating systems that we might be interested in. I think now this might be a good time to just take a quick pause and ask if there are any questions about this kind of basic usage of GitHub actions to set up some continuous integration.
Now we're going to move on to coverage checking now. What is coverage checking? Well, it's all very well that we can now automatically run the unit tests, but we want to have some way of determining. Whether that we've written are sufficient for the project that that that we're developing to take a really extreme example, if you've got a really old material project with thousands of lines of code.
And you've only got three unit tests, then obviously, that's not going to be covering all of the software, all of the functionality that you've written. And the question is how can you in an automated way determine whether and to what extent your unit tests are sufficient for the code base that you've been developing? And coverage tracking is one of a number of ways to give you an insight into the amount of your project that is covered by the tests that you've written.
And there are some third party tools out there to help with this. And what I'm going to attempt to do, and this will probably have to be the last kind of module in today's talk is attempts now to set up some automated coverage checking using a third party tool called Code Cards to Ohio. And if I go to code calls, that's why you hear. This is why I say I locked in, I've authenticated with my GitHub accounts and code couple of Io is free provided your repository is public.
If your repositories private, then you would have to pay a small amount of money to access this functionality. But it's free for public repositories. So what I'm going to do now is as a repository. And the easiest way actually is I can just type in the URL, so this is going to be my domain. And what this has generated now is a. An upload token that I will need to integrate into my GitHub actions workflow to allow it to basically puts the coverage results into the correct place.
So what I'm going to need to do is out this now, okay, this is a this is a talk for the purposes of getting getting you all up to speed with how to use GitHub actions. So I'm not super worried about security in this case. You can all write this down if you want to. It would be slightly annoying if you if you will use this to update errant results to you, to my credit card, but I can. I can always generate this token after the talk, so this won't be too much of a security vulnerability for now.
But I thought it would be important to show you how to integrate this service with GitHub actions. So the first thing I'm going to do is copy this token. I'm going to go back to the. Repository and in the settings under secrets. I'm going to. At this. Token as a secret in my GitHub repository, and it's a secret with the name code called tokens, I'd already set this up so. So it already exists that normally you press this button new secret.
So if that's the only thing we actually need to do to integrate code cards with continuous integration in this case, because it's a Python project, this is actually a relatively easy thing to get set up with the coverage checking. So I'm just going to show you now how to do that, going back to my idea in true Blue Peter fashion. Here's one I did earlier, so I'm just going to copy and paste my workflow from my my git folder, which was.
In the run directory, home and workplace. OK. And I'll just give you a quick go over of what's in this file, it's relatively straightforward and in fact, it's less complicated than the other two because I'm not using a matrix. In this case, I'm using a fixed operating system open to latest and a fixed Python version three point eight. And the install dependencies.
This looks exactly the same, except that I'm also installing two additional Python dependencies, one called coverage and one called code calls. So Code Code is a Python library developed by the website that we're going to be using to integrate this coverage information. And the difference here is that what I'm going to be doing is running coverage, so I'll get rid of that setting for now, and coverage is a an executable programme and I can cover its run. And then in this case, my unit tests.
And what that coverage programme is going to do is keep statistics about which lines of code were hit by my unit tests. Then if that coverage was successful, I'm going to run code cards, which will upload those results to code cards, dot the website that we were on, and it's going to use this secret too, that I've just sat in the GitHub repository as the token to ensure that it gets to the right place.
Now the nice thing about this setup is that because I'm using this code couple token, that's in the secrets. Anyone who's looking at this public GitHub repository. Remember, this is just a code file in the repository won't be able to see what this token is and therefore won't be able to abuse the fact that they could use that token to upload their own coverage results to your Code Cup instance. So that's all there is to it. I'm just going to commit to this and push it.
So it's coverage checking, and I'm going to push that. And now, if we go back to the Actions tab. We'll see that coverage is now running. And can we can just keep an eye on this? It might just take a few moments to spin up the virtual machine and get going. There we go. So it appears to have worked. So it's run the coverage again, all we see is that the normal output from the unit tests.
And then it's run code. It's detecting a lot of things that it's found the the XML files that it dumps out when running the coverage checking, and it's successfully uploaded it to code. Great. So now if we go back over to the dashboards on code calls and if I just refresh this or go back to the overview. Beginning. Refresh. OK, here we go. Great. So now we see coverage information and we see a graph here.
OK, it's there's not much code in here. So this would be more informative if you had more source files with more stuff in it. And we can see down here functionality by clicking here. Now, we can see the coverage report. So here I can see that pretty much most of the lines were covered were hit exactly once. What does that mean? It means the unit tests were successfully hitting these lines of code once, but actually we've got one line that wasn't covered.
Now this is something that you might not have noticed if you were just not checking the coverage, your files. But here this function is checking whether all of the arguments are actually numbers. If none of them are numbers, then it's just going to return. And then only after that is it actually going to go and do the bit of functionality that we thought.
So if I were to change this now, I could add in another test and the source sponsor if they're going to test functionality in test minimum, I could add another. Asset like a desert is none. CIA demo dot minimum. That takes no arguments at all. That should hit this new line of code. So if I were to save this now, commit this change. That's not what I want. Stage that and so ABC's coverage.
That's. And then whilst we're waiting for that to run the new job and hopefully update the code curve, we are running up towards 4:30. So what I'm going to say at this point is that there were a number of other things that I would have gone through if I had some time. But what I want you to know is that this repository is public on GitHub. So you know, there's going to be an opportunity in a moment to ask a few more questions.
I'll happily stay around and answer as many of those as you like. But this repository is going to be public. It's not going anywhere. If you want to try this out on your own projects, which I really encourage you to do, getting set up in the first instance is the hard thing. Once you've got the system set up, it's really easy to keep it working. If you have any questions about any of this or you're getting stuck on anything or you don't know how to do some particular thing.
Please feel free to come along to this repository and just open a new issue and tell me what you, what you're trying to do and what you can't do. And I'll get a notification about that, and I'll hopefully be able to to answer those questions for you. So please feel free to open an issue on this any time after this talk, if you're trying to set something up and need a bit of a hand with it. I'd be very happy to go over anything with you. OK, so now let's see whether any of this has worked.
Say it back to functional coverage, get back to see it move. OK, great, so now it looks as though it's slightly greener than it was before. I think if I go here, I can see that the coverage is now 100 percent like back into functionality. I can see that this line here that was previously not being hit is now being hit. And with that, unfortunately, there were more things that I would have loved to have gone over, but we've run out of time.
So with that, I'm just going to finish there and take any questions.