 So this is the second screencast about how to get test 161 set up. So in the first one, we installed it. So now in the same machine where you run sys161 and compile your kernels, you should be able to run a test 161 binary. Now test 161, what we'll talk about right now is its ability to run tests on your kernel. To do that, you run test 161 run. Now the first time you do this, or until you have this file, this is what it will print. If you need a particular configuration file, it needs to be created in your home directory. Nice thing is we can actually just pipe the output of this into this file. Now the test161.conf file can live in your home directory or in the directory where you plan on running test161. It's probably easiest to just put it in your home directory, so that's what we'll do. And then we'll look at this file and customize as needed. Oops. Oh, that's interesting, okay, doesn't have to work yet, so that's a bug, we'll fix. All right, so let's test 161 run, and this time we'll just grab this content, and then go into our test161.conf file, paste it in. So this is YAML. I'm going to take out stuff that we're not going to use yet. We'll come back to this when we talk about submission. The two most important things here are to add a path to the root directory. This is where you run your kernel, where your kernel gets installed. And then this directory is maybe a little bit confusingly named, so this is supposed to point at the place where test161 is going to read its own configuration files. Now if you've downloaded, if you've pulled our sources recently, you will have in your OS161 directory, at the root of your OS161 source, a test161 subdirectory. Let me show you where that is on my machine. So I cloned sources just recently, so these are, have changes from a couple days ago. Yep, I got the most up-to-date stuff. I just directly cloned the staff repository on GitHub. And you can see that I have a test161 directory here. This is located in the root of my source directory. And if you look around in here, there's some information, and we can talk about this in a minute, but these are all configuration files that control how test161 works. So that's that directory that you need to set in your test161.com file. It needs to point to that directory. Okay, so now we should be ready to go. Let's go into our directory and just run test161 in there for now. If we run test161 run, what we see is we have to give it. A test or a target. So there's multiple ways of running test161. The one you're probably most interested in is the way that we'll run all the test way before assignment and produce a grade. So let's do that for assignment one. So this is a kernel that I built from the base OS161 sources. This doesn't have any assignment one solutions in it. And here we go. So what test161 is going to do is it's going to run a bunch of different copies of this 161 and run a bunch of different things in parallel. And you can see here that it completed pretty quickly. And here were the results. So now over here, it lists all the tests that were run at the left side. Here's the result and here's the score that we received. Happily, the base solution gets a zero out of 50 on assignment one, which seems right, there's no solutions. And so here's the output of the test and here were the points that I noticed here that the boot test earns zero out of zero points. That's because the boot test was a dependency of other tests, but actually not something that earns you any points. That also happened here with the semaphore test. So the semaphores work as the test indicates, but it's not part of the assignment so you don't get any credit for it. However, it was run to make sure that other later tests could run. So our test drivers for locks for condition variables, the synchronization problem drivers all require working semaphores. And so the test 161 driver knew that and tested semaphores to make sure they were still working. If they hadn't worked, it would have skipped other tests that relied on them. You notice in this case that there were a bunch of tests that were skipped. Test 161 will do this if it notices that those test dependencies have not been met. That makes the testing process a lot faster. So there's a whole series of tests here, about eight of them it looks like that were not run because other things didn't work. So let's try to figure out why that happened. So for example, for syncprobs sp1.t, why did that test not run? Well, the way that we figured that out, let me open up a teamwork session here, is by looking in the test 161 directory. So these, scroll up a little bit here, let's see what we can see. Oh, okay. Sorry, so I'm out of here. Let me just run that again. Let's just run one. Okay, so the test 161 sources are all, sorry, yeah. So test 161 has a couple of different subdirectories, and the tests are all in here in the test directory. So why, and what it shows me here is that syncprobs sp1.t was skipped, and that only happens because its dependencies weren't met. So let's look at actually what those dependencies are. Sp1.t, that depends on boot, okay. Semaphores and locks, and these are all groups. Test 161 allows you to group tests into, to identify tests using tags. This indicates that it's part of the syncprobs group, and these dependencies are all groups. So what this means is that it depends on boot, semaphores, and locks. So let's run some of those individually. So I can also pass a group of tests to run to test 161, and let's do that. Let's try to run the dependencies of the syncprobs test and see what happened. So I run the boot test, the boot test completed. So that means that my kernel booted correctly, so that's good. We also saw that the synchronization problem one that's way omitting depends on semaphores, that's because the way omitting test driver uses semaphores. So let's run that, run the semaphores group. That consists of only one test, and that's correct. So now by the process of elimination, we know that it must be the locks that didn't work. So let's run the locks group. That consists of a bunch of different tests, in this case one, lock tests one, two, and three. Those are all three lock tests that we gave you, and all of those fail. So you can see that lock test two, which is supposed to panic, did not panic, three, which is supposed to panic, did not panic, and one did not work properly. And this is not surprising. This is the base set of code that we gave you, and this is what it does. Locks aren't implemented, and so nothing will work. So this is how you run test 161, and there's a bunch of different ways to do this, and we hope that this becomes a part of your development and testing process. So if I want to run just one test, I'll just give you some examples of how powerful this tool is. Let me just run lock test one, right? So just run lock test one, and you can see that it didn't work, right? Or I can just run lock test two, that's very fast. I can run, like I said, groups of tests. That ran all the tests in the lock group. I can tell test 161 that I wanted to include the dependencies of all the tests that are run. This happens by default when I use a test target, like assignment one, but does not happen by default right now when I use groups or run single tests. So in this case, what it'll do is it'll run not only the lock tests, but the semaphore test because the lock tests themselves use semaphores, and everything always depends on boot. So in this case, the first thing I always do is make sure the kernel can boot, if the kernel came boot, then nothing else matters. So this is an introduction to how to use a test 161 as part of your development process as you sort of continue on. The other thing is we encourage you to look around in here, in the tests directory in particular, and use these test groups, write your own test groups, add things as needed. You can see that all of our tests, all of the tests that we're going to use as part of assignment one are in here. They're all organized nicely into groups. So if I want to run the CV group, I can do this, and that'll pretty quickly assert that discover that on this test that we gave you, nothing works. So this is going to fail, and it's going to show me that none of my CV tests already work. And as you iterate, as you write your code, you can certainly run the test by hand. The nice thing about test 161 is that it runs everything in parallel, and so things run a bit faster. Now, the last thing I'll show you is that you may have noticed here that the output is interleaved by default. So you can see that these are timestamps that are generated by the simulator, but in this case, you can see that this is, you know, there's cases where the output for multiple tests is being interleaved line by line, and that can be a bit confusing. So if you want, go like this. You'll see that there's a sequential option. Now, the sequential option does not run test 161. It doesn't reduce, it doesn't prevent test 161 from running tests in parallel. That's one of the nice things about this test, suite, is that when possible, it will run multiple copies of this 161 in parallel, and that allows the testing process to complete more quickly. However, if you want to see the output in series, rather than in parallel, you can run it with the dash s option. And in this case, you can see that rather than being interleaved, which can be difficult to read, the tests will run in parallel, but here at the top is all the output for the first lock test that failed. Here, starting with zero is the simulator output for the second lock test that failed. And let's see, where's the third one? Maybe it was the first thing that printed, I think. Let's see. Do I see lock test three in here? Hopefully I do. Interesting. That might be another little bug for us to fix. Oh, wait, here it is. It's the first one. Okay, phew. Yeah, lock test three. Okay, so lock test three was printed first. Lock test one ran here, and lock test two was printed last. But in this case, you can see all the output and it's not interleaved in a way that would make it confusing. So that's just a brief introduction to some of the things you can do with the tool. I think a lot of you guys will probably just use this to run our assignment targets repeatedly until you get a good score. This is an existence proof. I will kind of show you what you can look forward to. So in my staff VM, I have this set up to grade the assignment one solution set. And here's what happens. So, and this takes a little bit longer when you run it successfully because it's actually running more tests, right? So you remember when we ran it on the base solutions, there were a bunch of tests when we ran the assignment one target that were skipped because the testing suite knew that there was no way that they were going to work. Because they relied on something that had already tested and didn't work. In this case, that's not going to happen. Everything does work. And so the testing suite is not going to skip any tests and things are going to take a little bit longer. And some of these tests are kind of slow anyway, right? So you can see that CV test two does a fair amount of sleeping and spinning. And so that test just takes a little while to finish. It's almost done. Now it's gone to the point where it can run the synchronization problems. And boom, there I am, right? So check that out. So this is what you have to look forward to when you finish assignment one. 50 out of 50, everything worked, everything ran. And that's how Test 161 works. So I hope you enjoyed this. And the next one I'll do we'll look at actually using Test 161 to submit your assignments.