 all right let's get started so welcome everyone on our talk about how Docker can help you running the tests and we will show you a bit of a cool stuff what we have in our cool ecosystem but before we do it let's all agree that software is everywhere it's not only on our computers not only on our hand helps it also in our kitchen it's also in our living room it's actually also kind of drive our cars and it's all of it is written by us humans or pretty much most of it I believe and we as humans tend to do mistakes and to quote the one of the most important computer scientists at skirt Dijkstra if the bugging is the process of removing the software back then programming must be the process of putting them in so what kind of bugs do we actually face as software engineers we can think about the bugs which are quite scary so for example the one which hit Tesla and the problem was that the car clearance was too low and on the highway it was possible that the car can take the debris from the road and actually said the car can be set on fire so what Tesla did they patched the software send it over the network to all the cars and the bug disappeared then we have another one which is probably stressful so that's all good now yeah we just have a problem with the screen okay let's try this one I'm testing platform and Docker to run your tests with a bit of a chaos in the sense that you can influence your infrastructure let it be a network latency let it be CPU or IO and see how your tests how your services are behaving so then you can detect the failures and let's say verify if your circuit breaker works you have a failover logic working properly this kind of stuff so we can pass try to run the show but we have a bit of technical difficulties as software engineers that's the daily job right I think our talk is cursed besides you get more people than one okay yeah it's cool alright so let's start again we're gonna talk about how to use Docker for testing and actually we should have test our connection before because we got a bit of a problem with the with the display so we're gonna rush a bit sorry about that we want to keep the schedule so yeah before we dive into the demos from our query and let's quickly agree on one simple fact that software is everywhere it's not only on our computers not only on our handhelds it's also in the kitchen in our living room and in our cars and most of it if not all is written by us humans the developers and we as human beings tend to do mistakes and to quote the famous computer scientist Edgar Dykstra if the bugging is the process of removing software bugs then programming must be the process of putting them in so what kind of bugs can we face in our daily job there are the scary ones like the one which happened to Tesla cars where the clearance was too low and on the some highways you could actually set the car on fire so what they did they deliver the patch over software patch to all the cars and then it was fixed then there are the stressful ones which happened in one of the airports in Paris where they had a system for monitoring the weather and reporting to the pilots about the conditions and it was one year ago it was still running on Windows 3.1 and all of the sudden the system stopped working so for a few days they were struggling with not only rooting the flights and giving them a prompt update about the weather conditions but they were actually struggling to find the person who could fix it for them and then there are the funny bugs or maybe annoying for some people like the one which happened to a Swiss guy playing in Casino in Austria he won 57 million dollars but Casino said that it was a software bug and they offered him $100 in cash and the voucher for the lunch so how we can prevent those kinds of situations from happening in our during our job one of the most important techniques which we have available are the automated tests and if you think about automated tests probably the most common and the most used ones are unit tests and unit tests are great because they give you safety net with in sailing fast feedback and if you follow TDD practice it also gives you a very good tool to drive your design because you as a first user of your service can think in the detail from the end user perspective how your API should look like but with all the techniques we have for unit tests like for example mocks there are certain limitations and people tend to overuse mocks and the test kind of don't give you the full picture of what's going on with your software components we can try to break it down a bit and use the sociable test so we don't mock everything we have around but we only mock the third-party services and we wire the components all together and in this sense we have a bit more broader picture of how the interaction between our components is working obviously it's limited in a sense of still having just regular objects and still having probably quite excessive setup methods so we should do better and we always need to ask ourselves are the unit tests enough are there any other a higher level test which can help us answer the question if our cold will work on production do we have a confidence that when we ship our software everything will work as intended or doing do we need something better so that we can sleep during the night and don't wait on the pager to come at 2 a.m. and run to the office to fix it we as a Arquian community believe that high level tests which are running on production like environment give you this confidence and as a compliment to your presumably very broad and big set of unit tests you should also take care about writing higher level tests which run on the production like environment and this is where our comes to the picture so what is Arquian Arquian is a middleware for your test it's not yet another application it's not yet another testing framework it's something which runs underneath and takes care of all the heavy weight work to set all your infrastructure components so that we feel the gap between the unit test and integration tests so that you can write your tests with ease focus on what's relevant for the test and forget about all the boilerplate code to set up your dependencies and set up your environment which tend to be an issue with integration tests back in the days and we don't only support if you don't only support integration tests we actually support any kind of high-level test you can think of let it be black box rest testing let it be UI tests and so on so the principles we had in mind when we started writing Arquian first and foremost were portable tests and what portable tests are is you don't have any notion of your environment setup within the test code so as test code so as soon as you have your test and the minimal configuration which is not in the test itself you can easily swap the environments or your application servers for example and the test will run on them without any changes in the code the other idea we had in mind that running those kind of higher level tests should be equally easy from your IDE and from your build tool so you just hit your shortcuts run tests and then it runs exactly the same way as JUnit, TestNG and so on and we don't reinvent the wheel we reuse best-of-brit tools we have support for JUnit, TestNG, Spock and all the cool testing frameworks and also other complementary frameworks for integration tests and UI tests and so on and since we cannot foresee all the new cool things which you come in the future we build it in the way that it's super flexible to adopt so we have quite broad community which brings new tools like for example the one which we're gonna demonstrate it in a minute to run docker tests and we are extensible to the new platforms we have a very flexible SPI model so it's fairly easy for you to bring the feature which you cannot find currently in our ecosystem and just implement a bunch of interfaces and then you can easily leverage Arculean platform to run your tests and obviously another important thing is the ease of deployment and nowadays with docker taking over the container world your deployment might not necessarily the deployment unit might not necessarily be a war file it can be actually just an image so let's see how we can leverage docker not only to bundle our applications and ship them to production but how we can leverage it for running the tests so in the world of Arculean extensions the extension that deals with the different docker files and the docker build and so on is the Arculean cube extension what it essentially does is to allow you to it allow you to kind of abstract away the life cycle of the docker containers that being the starting of them the deploying of them the registering of them the kick the killing and removing and also the whole build at all build cycle of them and it's worked on the local docker demon as well as OpenShift 3 and Kubernetes so so this specific talk we're gonna focus on a very specific particular sub extension of you begin we're seeing more and more as we go online with our tools we need to be able to be offline as well because whenever you're out somewhere and you want to send an email and you can't because you're not online at the time so this is where the docker cube cube comes in which is an extension that provide kind of chaos to your docker environment is three different main types of chaos is so it's the container chaos that allows you to stop kill and remove random containers or specific ones during a test scenario it's the operating system chaos which essentially funnel with the internals of a specific docker a specific docker container so you can block poor ports you can burn the CPU you can kill the IO and so on to see how the other services for instance react to this process slowly dying and it's the third one which is the network chaos where you can intercept the network between the different containers to slow it down to kill the connection and all those kind of interesting things to see again how other services react to it so the thing we're going to show is the network chaos part of it which is based around the toxic proxy what cube does is to install proxies in between all the different services and then gives you an API to control what's gonna happen to those different endpoints so in the first part is you have your normal setup and then when it's been it cubified or toxified whatever you want to call it then you get the different proxies in between and you can you can manipulate this link and you can manipulate that side of the link and all the other links that are in the system so the cube is using docker compose as one of its formats to configure itself in this demo we have a simple hello world application that is communicating with a ping pong service to get this huffing back it's just two different images there's one job application and one I Python something I believe and when you're using cradle the only thing you need part of the test compile scope is the cube Q toxic extension and then everything else kind of gets pulled in from there as far as the test case so you're injecting the network chaos Archealian resource you have the option to inject in the host IP of the docker host or the open-shift host and then you can do in a in a in a closure like callback syntax you can say that when someone is calling ping pong on port 8080 then change to the latency of that hetero connection so when when during this internal call essentially that network will be tweaked in some way of way yes yes yes so let's have a look at how this looks in practice whatever my there we go so this is the example so the first time we're just gonna call it with no a with no interruptions at all and then we're gonna set up a we got yeah okay so so we're gonna say that for 15 seconds then we're gonna do a timeout thing and for the next we're gonna have a latency for the next 15 seconds as well so we continuously execute this as fast as we can but but during the whole network troubles set up so we're gonna run the demo and just using the grail demon we'll see here that the the docker container starts to pop up and we should be able to see the hyperics stats that are happening during the this execution so the the first part is fine it's just a executing executing a continuous one and then 15 seconds in it's gonna start making trouble for that if connection you should see the different stats essentially slowing down oh sure sure and at this point is starting to get trouble with the latency call and no well now it's actually in the stop that connection fully as the circuit is open and it's slowly shutting down the different containers and that should have left us with a build success as far as our testing is concerned any questions around that so this is just the the service that kind of counts what's happening within that service at to so you can see that in the first part as far as as far as it's running I come so currently it's counting all the individual connections within our 5 within our 15 second loop right and you can see that they all go green by it's all fine and then the latency starts to pop in and you will see the number of requests go down essentially and then at one point the circuit will be open meaning that the whole connection is heavier than gone so we can't get anything through which was also kind of part of the test scenario and this is where it's starting to okay there's something wrong now it's all gone it's dead so it's just kind of verifying that the proxy is doing what it's supposed to do and you can see the communication happening and yeah it's just an interesting quote in the sense that moving to a kind of docker environment it's not or no sorry not a docker environment to a test to the automated test solution is not mandatory but then again it's not mandatory to survive in the next world either you so previous speaker was Bartosz he's the Arcelean lead and I'm Arsala Knewson the Almighty lead that was all for us