I just wanted to show a little scenario we had in the desktop client development. I don't have a PowerPoint, I'm not very well prepared, so maybe it's not going to be entertaining,

but anyway, so the story starts when we needed to have this behaviour here. This is a write-only directory that I tried to put a file, and the feature was that we wanted the overlay icon to basically show a warning on parent folders.

The problem with the overlay icon code at this time is that whatever you touch, you break two things, so there was no way to go toward stability because you always break more things than you fix, so we needed tests for this, so the talk is going to be about what's

the current testing that we had, and how I had to adjust this to support testing over the icons which is going a bit deeper in the architecture. So I'm going to show you the current testing we have.

Those are tests that Klaas wrote back then. This is running in a Linux VM because it needs to run on Linux. It needs a server, and you need to set up a config file, and it's basically, it's not always trivial to set up, but the moment you have it, it works.

And the code is, the code looks like this. It's basically just doing something, running the onCloud CMD command line tool and then checking if everything is the same.

So okay, now the interesting part. So the basic client architecture is that, let's say that we have our T1.pl test here. This thing is going to use the onCloud CMD command line tool, and here on the right

we have what we call the onCloud GUI, which is not going to be used in this case. And here we have what we call lib onCloud sync, and to keep it simple, here we say

that C sync is doing file access on the local drive, and you have Qt network doing the server access.

So here we have the server, and here we have the disk. And the way that those tests are working is basically that they go on the disk using normal file access, and they're going to write something, or they go on the remote

and do something else, and then through here they're going to check and trigger something, and at the end they're going to check is everything the way it's supposed to be. The problem with this is that the overlay icon code is around here, and it was very spaghetti code, it was around those two layers, and this thing has a local socket,

and you don't want to be able to, you don't want to try to test this because the socket code is a bit different on each platform. So what I needed is an eraser, so let's just try this.

So the way that I'm going to fix this is simply by doing this here, and by doing this here. So I don't want to have to set up a server just because it's a bit better, and I'm going to, I have refactored all the overlay icon code, basically to be all in libsync, to have

something that just tells the signal there's a new icon coming, so I just want to know is the icon correct, I don't want to know if it's passed on the socket correctly, this is logic that is straightforward and we don't need to test this, but all the complicated logic has been moved on there. So now what the test does is just using a unit testing framework, and it's going to

test the proper signals from the overlay icon, and the interesting part here is that I'm going to have a fake account.

So the test is going to control the fake account, which is just a thin layer over Qt network, it's basically a fake network request, and it doesn't have to go through a server, you don't have to configure a server, you don't have to configure credentials, you don't have to upload any files to test, you basically just tell this thing store

the structure in memory and make sure that everything is the way it should be. Okay, so this is how the parallel test looked, and this is how the new test looked. Basically you have your fake account, which is a folder connection in client code specification,

here I'm going to check for a signal, so here I'm checking did the item complete properly, did the file A0 has been completed, I'm just checking this, and I'm comparing that the

two structures are the same at the end. So the code is not that much bigger, it's about the same thing, but the advantage is that this code here took one minute 15 to run, and if I run mine here, it takes one second.

So that means we can have more tests that we don't need to configure, it doesn't matter. So the test can run faster and we don't need to configure them, and we can go further on inside the engine to test something. So an example for my overlay icon code, I can do stuff like this here.

Okay, so here I start async, here I'm going to wait until we did the update that we discovered what's the server side and what's the local side, and it stops at this point

because the way it has is Qt has an event loop and we can just listen on the event loop and at some point just stop. And then I check some stuff from the status, from the socket API status listener, did I receive a new sync status for this, did I receive a new sync status for this, and

then I try until the defolder was propagated, check again, and then I continue until the sync is completely finished, and then I check the states again. So there's no way you could do this with the C sync test because of the previous test,

because you cannot interrupt the sync in the middle, you just have to do it once or you do it completely, and it's very difficult. So this is how you write a test. I mean, the whole point in presenting this is if a class wants to write tests for this,

if you want to write tests for this, this is how you do it, but the nasty part is that you have to implement all the server features in the fake account. So this is going to get a bit bloody. Where's my code?

So I have this big class which basically implement all the fake server and all the stuff. So for example, I have let's go to a fake put. So here the fake put is basically receiving the network request, I mean the code doesn't

matter so much, but just to say that this is basically doing exactly what the server is doing. So if you want to test chunking, if you want to test batching, you basically have to re-implement a fake batching inside this code to be able to test it. So it's worth it for overlay guns, for other stuff you might want to use the Perl tests,

but we have both of them, and the advantage with this compared to Smashbox is that you can have error cases, you can tell the fake server, return a 500 in this case, right after return a 200, you can start interrupting connections in the middle, you can do stuff that you couldn't be able to do from the outside.

Any questions, Klaus? Could we use that to simulate a broken server as well for the completely unusual case that

there might be a bug in the server, so that we could finally test error conditions which we couldn't until now? Yes, very good question, thank you. So, for example, in the case here, I have a fake error reply that basically returns

a 500, so you just need to tell the fake account, in this case I think I have it in one test here, because for the overlay gun I needed to test errors, so I just tell

the fake account just for this path, return a 500, I mean right now it's just there's one case, it's 500, but if you want you could say return the first six bytes and then stop the connection, you could do anything you want, because you can simulate the whole Qt network in this case.

How do you test the fake folder code and are you running Smashbox tests against fake folder? No, the real code is testing the test code, it's a synergy, so if there's a bug

if there's a bug in the test code then the test is going to fail, but if you have two bugs and the bugs cancel themselves then you have a problem, yes.

Thank you.