 I'm going to need to switch ground. OK. That's good? OK. I'm just trying to move the presentation here. That should work. Let me just check my clock. OK. What's your name? Bartosz. Bartosz. Yeah, it starts from unit testing then goes a bit system testing. But it's pretty much basic principles and practices. Sure, sure. Can you see the notes? It should work. It should work. I didn't expect you to slow this down. Well... Let's give us some background. And I think everybody is looking forward to see about the testing. And make something better. OK. My check. I'm not sure if... Yeah, you can hear me anyway. So hello everyone. Thanks a lot for coming. It was quite a maze for me. I had to ask like two people to get here. So I'm very happy to see so many faces. When I was giving this talk the first time, it was pretty much full of pain and frustration, tears and blood and losing hope. But I think we are in the country where beer is the main drink. Maybe not in this area. I work more about wine I think. So the theme will be beer because beer is good for everything. And it will be about testing. I'm mainly a Java guy. So the examples I have for you will be in Java. However, I think that the principles and practices I'm going to show you, you can also apply in the other languages. And hopefully with what I will present today, you will be able to write easy, readable, awesome tests and have fun doing so. Alright, so let's start with the simple things first. Assertions. This is pretty much the thing which we have in most of the tests because we test for a stage as well as behavior. But tests with assertions are pretty much the most popular ones. So the first part will be focused on assertions. So let's have a look at the first example. So the first example is the test which where I interact with some repository trying to find the strongest beer in the world. You can see it might be a bit unusual for Java people because I'm not using Camelcase for test method names because test methods or tests in general for me, they should tell the story. The name of the test, yeah? I'll try. Sure, it's 500 and it's still... Unfortunately I cannot, I'm sorry about that. At least not in a few seconds. I probably can rebuild the presentation and then make it bigger but for now I'm sorry for that. But anyway, so I tend to give the descriptive long names and I prefer to do it with the underscores for several reasons. First of all, the Camelcase doesn't read well when the descriptive name is so long and if we stick with regular Java testing frameworks we use test methods as a description for what is the feature we are testing. And another good reason to do so is that it's very easy to find the stack trace. So for these two reasons I really favor using underscores even though most of the people I work with were very skeptical at the beginning because it breaks the conventions, right? Okay, then the structure follows a bit of a BDD besides given. So normally the BDD has, for example, given when then blocks, which is coming from Gherkin syntax, where given is an initial context of your test where you set your expected results and the context of the test then when is where you actually exercise your component under test and then in the then block you either assert the state or you verify the behavior if you use mocking frameworks. So having said that, there are better tools to write BDD in Java, in Go, in .NET, everywhere but I will stick to the JUnit-like syntax for the moment. If you are looking for more expressive frameworks and you're a Java guy, for example, ECB or Spock, these are both groovy frameworks or even Kotlin has a very nice spec framework which is also very nicely structured. Going back to the simple example I have, there is already at least one problem here that we use basic assertions which are available in the testing framework and this gives a narrative of the test a bit hard to follow because you need to kind of dig into the whole context here and figure out what's actually the subject of the test and also you might mix the order of expected and actual and then errors in the tests are becoming kind of tricky. So this beer in particular is real it's 67.5% comes from Scotland never tried, I'm not sure if I will but how can we fix it? So if we would have more tests like that with similar pattern of assertions the first thing which people tend to do is to make a common extract and method and just give it some different name and just pass all the parameters and this obviously follows the dry principle so don't repeat yourself but as I said I like to break conventions and I don't really follow dry in the test at all because as I said at the beginning the test should tell the story but when I look at the feature within the method and I see exactly what I'm testing rather than having something which will let me jump to this method and figure out what those values are standing for but that's already a small improvement what we can do better however is to use custom assertions there are a plethora of frameworks in Java also in other languages which let you do so so one of my favorites is AssertJ and this gives you fluent interface or a DSL where you can actually say exactly what you're testing this is a custom assertion which some of you might think it might be tedious to write by hand however AssertJ comes with plugins for generating those so if you use Maven or Gradle you can just have a step in your build which will do it or you can have an ID plugin which will do the same for you but the main principle here the main idea is that having this kind of approach gives you a very good understanding what is the subject of the test rather than verifying a lot of assertions and trying to figure out what was the purpose of the test which the other person is writing so let's go to a bit of a more sophisticated example not that much but still we probably having a repository would like to assertion collections and this is again the regular pattern five AssertJ quals already something which is very smelly because you shouldn't have that many as this introduces not only a noise but also introduces an issue where one of those on the way will fail because that would lead to some sort of a snowball effect trying to figure out what's the issue and fixing one step after the other with AssertJ we can do it a bit easier it has assertions for collections built in so what we can say as you see in this example in the previous one what I'm doing I'm actually getting each of the elements and extracting the name and comparing it to what I'm expecting to have these are actually a checkbears which I tried so over the weekend pretty good what we can do if we are not in Java 8 yet we can have an extracting method which will get the name obviously it's not very factoring friendly but it gives already slightly better structure if we do use Java 8 and if you are Java guys you all should because it's gonna be deprecated anytime soon when Java 9 eventually be publicly available we can use a method reference I was thinking when preparing this example to put Pilsner Rookwell as well because that's not a check beer anymore it's owned by Japanese company but still produced here so I put the Slovakian ones I know still the problem here again is that if we will have size bigger than 4 it will fail we won't be able to reach this assertion what we can do with assert.j is to use soft assertions and this just gives two extra lines if we don't use JUnit and then it will be all grouped and reported at once if we use JUnit however we can use a rule and then the assertions look pretty much the same as the previous example so I highly recommend using assert.j this makes your life very easy and it has a lot of other interesting features question, yeah? sure if for example in this case the size would not be the one that we expect the test following after that could also be meaningless at that point exactly, it's actually this one maybe not this one, the previous one when I had all the 4 beers I was checking it's a bit redundant, that's true I'm one of the principles the question was does it make sense to have two assertions in one test which one fail actually eliminates a need of another or actually the second one makes the first one redundant that was the question adding noise to my... sure, that's a very valid point so normally the good principle is to have one aspect or one functionality per test which normally boils down to one assertion and this is what we should follow, that's true I mean, these are not perfect examples I agree, I just wanted to show in the smaller snippets what kind of features there are but normally your correct one assertion per test should do the job, especially in unit tests that's totally correct if you really have to have more than one then the soft assertion will help you because then it will group all the issues all together you don't have to repeat the test one execution after the other to figure out if the next assertion is failing or not but normally as a rule of thumb one assertion, one functionality per test should do the job and another pitfall or another smell I've seen so many times is that you test some logic, you throw in assertion then you test something related you throw in another assertion and this is obviously a candidate to refactor to two different tests because these are two different functionalities so thanks for this question the example is not perfect but maybe it was provoking to have this question as well so the other cool things we have as I mentioned is the code generation so you don't really have to write all your custom assertions for your business objects for example by hand you can use the scaffolding and then adjust it if you want so maybe the names which the generator provides are not what you like they are not too descriptive you can refactor but it's a good starting point and it also comes with the automatic conversion so if you have already a project with a lot of J-unit test and G assertions or FEST which was the predecessor of AcerJ AcerJ provides a tool to convert them on the fly so you can introduce very easily a new way of writing assertions if you like AcerJ and on top of that it comes with quite a bit of plugins if you use for example collections from Guava the standard ones like multi-maps and so on there is a plugin for that if you use Jodatime then you also are covered then for database testing or Neo4j there is also a custom one if somebody writes swing then there is also a plugin for dealing with swing using AcerJ for me the main benefit of using AcerJ is actually code completion there is another very popular framework which is called Humcrest and it also gives you a very nice way of structuring your tests or assertions which you can read pretty much like a natural language my personal problem with it is that it's all based on static factory methods for Humcrest and then on them you can say like is equal to something but you lose the support from IDE because in AcerJ you have an entry factory method which gives the assertion aware of the type you are testing so you have a support from IDE showing you exactly what you can verify with a given object and on top of that it also reads very natural at least from my perspective so that's a pretty brief introduction to assertions the key takeout for me is that we should write the tests that have a story there a narrative that assertions are oriented under your business domain you are testing and AcerJ gives you this capability pretty much out of the box what we also should do in unit testing especially is not only to test happy paths like my examples were showing we should also think about boundary conditions and one of the boundary conditions are error tests so testing how our application behaves when we pass some wrong values or if we have a correct exception handling and so on so the test taken from one of the projects I've been working for obviously not the same business domain actually had some sort of a BDD flow it was very hard to read because first and foremost you have try which gives a noise and then you have this very smelly turn in the catch block and then there is fail at the end the easiest way to fix it is to do as recommended or as logical by using fail method from Jagend for example pretty much you try where this is a method which is expecting to show the exception and if the next line is reached then you just call fail this is already not so bad there is still try which introduces some noise so there are tools which can let you do it better if you look at JUnit in particular you can test for exception just by defining it in the annotation and personally I think we shouldn't use it because we don't really know obviously these are two lines of code but sometimes it's a bit more than that we don't really know at which point the exception is expected to be thrown and if we don't have our own custom exceptions or we use two type which is too broad we don't really know what happens so expected exceptions by using just a test annotation from JUnit we should avoid and therefore JUnit comes with the rule which is called expected exception and this thing lets you be more concrete lets you set your expectations closer to where the error can occur I've seen people setting it up at the beginning of the test and this is a bit risky because it might happen that something on the way can throw similar exception and then you don't really know what happens so if you want to use expected exception then rule of thumb is to put it as close as possible to the method which actually can cause the error we are testing for so we not only can specify the type of exception we can also specify the method we are expecting but we have better tools for that if we are before Java 8 there is a small library which is called catchException and this pretty much proxies our component under test and lets us inspect in a more narrative way what was the problem with the or what was the error that our component under test thrown it's great except that the author stopped maintaining it when Java 8 came out because he said with Java 8 it can be fixed with just one lambda and makes this library obsolete so with AcerJ again we can do it in two ways it's pretty much both down to the same depends how from which angle you want to look at it you can say assert that thrown by and then you give the lambda block and then you verify the exception or you do it from the other angle you assert that the exception is thrown by with the message you have two ways, depends on your personal taste I think this is the most concise for me and most readable way and it tells exactly what we are expecting from this to happen for non-Java guys it might look a bit awkward I guess but from my personal experience that's the cleanest way of writing this kind of error tests question should it be the creating of the your abstract of the assertion so you can distinguish which part absolutely, you can actually you can put the given block which will be your stimulus to your test out of the shore, absolutely that's right and then you only have exactly the fail point wrapped in the lambda sure the next anti-pattern or common way of dealing with asynchronous or asynchronous calls is something I would like to spend a bit of time on so we can look at another example again about the beers we can have a service which places the order and this might be asynchronous so this approach will immediately fail because might be that this state was not updated yet it's not really a unit test because normally we would probably mock it so we would get an instant answer but if we go a bit higher than unit tests we will face some cases where asynchronous calls will be taking part of so the easiest and naive way is to just sleep, right? we just wait 200 milliseconds works on my machine we push to Jenkins for example and then it fails so what we do, we increase to one second it looks funny, it looks probably embarrassing but I've seen it so many times that I really thought it's important to spend at least one minute on this topic the other, and also you can see it in UI tests probably UI tests are those where you see it the most so we can make it better with one tiny library but before I show you one last word about this approach is that we pretty much expand our build time by one second and each and every time we invoke it which is first of all not needed and second of all pretty smelly and painful there is little library for Java which is called awaitility and this gives you a way of wrapping your call and then for example pulling it for two seconds until the condition is satisfied reach probably better, won't wait two seconds until it's finished by default it pulls every 100 millisecond I guess but then it's closer to the real response than putting a brutal thread slap in the code thread slip and this is what I was referring to before to huntress these are the static methods which you as I call it onion and it's readable more like a natural language if you like to use assert.j again you can do that the library provides also a way of doing it by just passing a lambda with verification so if you have to deal with asynchronous calls forget about thread slip for simple cases and for UI test awaitility which boils down to one line of calls eventually will do the job for you and your test will be less flaky, faster and way more readable additional benefits from awaitility is that it actually is able to detect deadlocks on top of that you don't need to have this fixed polling mechanism which pulls every 100 millisecond if you know you are dealing with something more sophisticated you can use maybe Fibonacci sequence you can use an iterative so every polling will be multiplied by two or if you want to do something more fancy there is also a very easy SPI to do so so if you will need to deal with asynchronousity definitely highly recommend this library it's very tiny, small jar, not a lot of magic and tests are way more readable your friends from the project will thank you after some time for sure ok let's jump a bit to the higher level of tests and let's talk a bit about testing REST endpoints so again we have an endpoint which returns strongest beers let's say I have just those three I'm aware of I'm not sure if you see it clearly but this is the actual bottle of this beer not produced anymore it was wrapped in squirrels Scottish brewery called Brewdog ok so the thing you can see pretty frequently is to use for example Apache HTTP client again taken from one of the projects I was working in so we have an initial context where we just set a get call then we set the clients then we need to do something with the response so we unwrap the body we can check the status and then we need to do something if it's JSON with return JSON and then assert on the elements of this response and then obviously at the end we have to clean up the connection otherwise we might end up with some memory leaks so there are several problems here first of all it's not really clear what's going on there's a lot of levels of abstraction which introduces noise but the test doesn't tell the story the right way there is a very nice library which is designed for testing rest endpoints I mean I've seen people using it for just interaction with rest endpoints but I wouldn't recommend because it's quite maybe not heavy but it uses groovy underneath which normally you don't need to especially when groovy is used for asserting you don't need to bring so many dependencies just interact with rest resources but for testing purposes it actually provides you a behavior driven way of defining what is the interaction and what would we like to know about the response and personally for me it's way easier and it tells exactly what's going on if you compare it with the previous example we have probably like 3-4 times more lines of code and this is doing exactly the same thing again what we can do we can assert on the status and then there are several ways I will show in the follow up examples what we can do with the content the easiest thing which is probably too happy a case is we can assert on the sides what we can also do is obviously having some query params we can also do the testing for example limit on the return collection here there is a convenient method which is called param and this will be then inferred based on the HTTP method called either to query or path params but if you want to be more verbose or more precise there is query param and path param available as well and then there is, if we deal with JSON it provides some sort of a JSON path expression where we can just extract all the names and verify the content of it we can do better things with verifying the content as I said it comes with groovy so even though it's a string in some ideas you can inject support for the given language this is g-path which comes from groovy and g-path you can think about it like similar to x-path it basically is expression language which lets you interact or inspect the structured data so it works with XML it works with JSON out of the box here what you see I pass the I call the find all method which is the method available on the structured data with some condition on it and then I can call a size for example and I can verify the content so if you have a bit bigger payloads or bigger responses there is a pretty convenient way of verifying those as well but obviously sometimes something can go wrong so we can lock what's going on we can lock pretty much everything what's concerned about the requests params, body, cookies, method, path or everything and the same for response whereas in response we can actually leave some of the logging for the tests because the previous request logging is probably only useful when you have a test failure and you want to see what's going on then I normally remove it because it's a noise and lock will be super huge in your build or in your CI environment whereas for responses you can actually have some conditional logging for status or validation failures or if you have some custom matches just a tip of an iceberg the other interesting things we have in REST assured we can have a request specification so we can have one shared request spec when we have for example authentication or some other common elements extracted in the setup method and we can share it across all the calls in our tests this will give us cleaner tests less duplication and reusable request spec we can have custom parsers so if we return something which is different than JSON or XML this can be used to handle this use case SSL support and we have filters which let you do something like intercepting request response doing some things with authentication with logging or maybe session management that's fine so yeah highly recommend using REST assured very good library for testing very descriptive and also very helpful when it comes to debugging and analyzing what's going on ok let's go one step further then because the previous example of interacting with REST resources was more thought about having calls to your own components but what about the case when we have to integrate with the third party services so we can for example have a rate beer service which is a website for rating the beers and we can check if our client code actually works as it should but there are certain problems about it for example we might not have a network network might not be reliable we can have a limit on the API calls we can have some other random things because the component we are interacting with underneath is not under our control so how we should deal with that we can have our own fake ACTP server so we can stop responses we can have quite a bit of boilerplate code to do it but this probably is good as a first step the issue with this approach is that we might not really reflect the reality so the headers and the content is just our understanding and we will have to maintain it having the knowledge of the third party service so good as a start but probably not good in the long run so we can mock ACTP layer as well but then again we are working we are testing in the setup where this is our understanding of how the things are working and we are not really sure if the contract between us as a consumer and the provider is still guaranteed it's still respected so one of the approaches which you can consider is so-called service virtualization so again we'll be showing Java examples but there are tools in Ruby there are tools in JavaScript to do the same the idea is that you can have some how do you call it like a thin proxy in between which will let you go to the real service but on the way it will record it and then the next time you run it will pretty much just use what you have so in JavaScript there is a tool called prism in Go language there is a tool called VHS comes from the inspiration comes from Ruby it was VCR I think that was the name of the testing tool so in Java we are a bit better than Ruby we have Betamax for example there is also a tool which is called Wiremock which can be used for exactly the same purpose but with Betamax you have just a tiny little annotation and the magic happens underneath if you use JUnit so Betamax is a concept of tapes so this is the name of the tape which is pretty much just a file storage with all the interaction happening between us and the third party service it works as a transparent proxy if we set up the JVM correctly if not then you have a way of just having an HTTP client which will serve the same purpose so the tape is just a YAML file it has everything captured you can also have some regular expressions it handles the binary content as well and then we have several strategies we can have read write which was what I was explaining before so the first call if there is nothing will go to the real service then on the way back it will be persisted so the subsequent runs will be using what we have in the local storage then there is read only which means we assume we know what's going on there is no network probably so we can use it just with our isolated environment the write only will just overwrite everything and then there is another two cases read sequential and write sequential this will just go over the whole tape and without any matching will reply the request responses so one tool for doing service virtualization with lightweight quite simple but for a lot of cases very usable if you want to have more control then wire mock might be the better choice for you okay then let's talk about the UI test as we are going higher and higher in the testing pyramid which I personally don't believe we should use as a silver bullet or the hierarchy of tests blindly but it's a good starting point to think about the amount of tests in your project so the UI tests most of the times even if you are not a Java guy you use WebDriver Selenium WebDriver which are now the same things so again the example of the tests which I've seen pretty frequently in the project which I would assume came from Selenium Firefox IDE which lets you record and gives very low level operations on the browser on the DOM and this is just not readable just terrible code right we have ThreadSleep which I was talking about some magical IDs we don't really know what's going on except of the name of the test itself and then I'm not sure if you know what this 13 should be doing it's pressing enter right but yeah it's probably not the right way of writing your tests I mean might work at the beginning but as the project evolves and people are changing you will probably delete those tests afterwards so there is no benefit of having such beasts in your code base so something which is actually suggested by Selenium WebDriver Fox is to use page object patterns how many of you have heard about page objects just a few so basically the idea is that you introduce classes the character of classes which model your UI and this is what you use in the test itself so it abstracts away what is the interaction with the browser because WebDriver is not really a testing tool it's a browser automation tool so page objects will give you a way of structuring your components and hide the complexity of your tests in those and expose the interaction with your web app through some meaningful methods which actually describe more what user is doing but not what browser is doing and that's the main purpose of it so if we would look at the slightly re-written test I think it's a bit nicer to follow what's going on so we create the page which is encapsulating our website we need to pass a driver which is the WebDriver object, a URL which we would like to use in the browser but then all the other interactions are described more in the way of how user would do it if we peek into the class itself it's just simple encapsulation with the way how to locate the elements and then how to interact with them but again you can reuse them across all your tests and you hide the nitty-gritty details so the tests are telling the story almost my personal experience with the page objects over the time with the not so big team, different skills is that it's getting very hard to maintain and it can result in God objects so we can have an object which represents the page with everything that's in the page and then it's like 2,000 lines of code and you will be lost after a while trying to figure out what's going on when the test fails and UI tests tend to be flaky unfortunately and on top of it it violates single responsibility principle because if you look at the class itself it first defines how the elements should be located and then encapsulates the interaction with it and then on top of it as I said the test should tell the story but who am I in this test am I a browser? a page? I mean it's a great starting point people who are strongly involved in acceptance test driven development they came up with a better idea some of the shortcomings of page objects like for example huge classes with a lot of logic responsible for finding elements this can be solved with another framework built on top of web driver which lets you define page fragments and then you can slice your websites to smaller bits and then reuse them so you might not have an insane hierarchy of classes and insane amount of web elements which are the smallest bits of web driver DOM representation but you can mix some smaller fragments and reuse them like for example calendar widget or whatever so there are things which are making it nicer just obviously as I said web driver is a browser automation tool there are some nice tools built on top of it which makes you write test more concise and more user oriented for example from Groovy there is gap there is a lot of selling ideas another one which is more oriented towards testing the page rather than clicking and opening but another approach to fix it is some evolution of page objects which is called journey screenplay pattern and the whole idea behind it is that its user is the entity of your test is the key point of the test and you see exactly that the user plays a role there is no browser open no page search for and so on and so forth another idea which it promotes is that the components are small and reusable and they are highly readable at least that's what they say the code is a bit small so I'm not sure if you can see from the bug but what it says given that Bartos was able to start the app when I attempt to search then I should see that it has this item so there are frameworks which actually gives you those small building blocks and then the test will be written in this DSL fashion if we look at this part which is still hiding the real interaction the page the journey pattern has roles, has actors has tasks and actions underneath so these attempts too can be broken down to entering the value into the search field or hit the return or enter key on the search field obviously you would like to probably hide it because this is not appropriate level of abstraction but the key point here is that you have those small components which you can build together and have tests saying some story actually so as an example there is a Serenity BDD framework which came from Java and now there is JavaScript version using Protractor underneath if you would like to know a bit more because actually it's a topic for the whole presentation that's a short link explaining all the details all the ideas behind this evolution of page objects and that's pretty much all what I wanted to share with you so just as a recap if you write tests do it well or don't do it at all because if you write ugly tests, flaky tests there is no benefit deleted because it will just cause problems and it will add time to evolving the project so tests should tell the story one way of using it or doing so is to have custom assertions strongly encouraged to avoid wrong abstractions and boilerplate and from my perspective tests should be readable, they should be repeatable and probably most importantly reliable and that's all I've got I'm Bartos Maesak, I work for Red Hat in DevTools tell me your thoughts about the talk, that's my twitter handle if you want to see what I'm hacking, that's my github I'm originally from Poland so thanks a lot for staying with me we still have seven minutes I guess so I'm open for questions so probably won't be able to show it now the question is can I show how to create custom assertions not ready for live coding but what I normally do not only for custom assertions but even for tests when I want to have some DSL I just write the test in the way I want to read it and then I implement it but for custom assertion in particular AsterJ comes with the generator so you define an object you want to have a custom assertion for and then it will go over all the fields it will generate the methods like hasName, hasAge, hasSomething and it's very similar like you would think about builder pattern generators for IDE, for Eclipse for IDEA and so on Visual Studio has it for sure as well but normally my take is I just write it the way I want it to have I have compilation errors obviously but then I implement it and that's a bit of discipline but it pays off dramatically I mean these are so simple that normally you don't I think but that's a valid point I mean testing your tests it's another interesting topic if you said yeah, sure but I mean it boils down actually to reusing existing assertions most of the times you have primitive types or some collections and these you have already out of the box in those libraries and there is no point of testing these libraries assuming that they are tested well about testing your tests there is interesting topic about mutation testing but that's another thing probably for another talk but if you are interested about the crazy idea of testing your tests have a look at mutation testing concept okay, thanks a lot I'll have the next time the best practice to test your services suppose I am developing the REST service and I won't write tests so these tests are running with my unit test so you are developing the REST endpoint yeah what I was normally doing what I normally do is I test the components which are served then as the REST resource as a unit test so the business launch everything and then I have few of the happy paths and some boundary conditions as a black box test for the REST API so that's normally what I do there is another interesting concept for doing that which is called contract driven tests so when you have a producer and consumer you define the contract between them and then providers so your REST resource you try to do it at some point you need to implement what are the expected behavior or expected payload or whatever but this you can use even before your REST resource is implemented from the client because you agree on how the interaction will be going on so that's not a new concept because I mean SOAP had the same with contract first approach just nowadays there is more and more tools not only Java then PACT is one of the tools which is providing that and it works for JVM it works for GO it works for JavaScript and I think for .NET and this is all about contract testing so you define the contract interaction how it should be then provider will eventually comply to it but client can start implementation of its own because it's like a mocked or stopped request response but how to organize it if I would like to test REST service it should be deployed somehow how do you automate with this stuff so if you use these tools for contracts or even stabbing it with my wire mock you don't need to because you just are interested in the payload right so this you can store other than that there are tools for you should have so normally what we were doing we were just deploying it automatically with some predefined set domain data these are not integration tests but such system tests so basically you are testing it already in continuous integration not on your machine also on my machine because there are tools which let you start all this stuff straight from the test for example come to my talk at 3pm I'll show straight hopefully this demo will be working but we'll see okay cool how was your talk I don't know you tell me I was not sure sorry okay well I said what I was planning to do so I lost only two guys had some questions I watched it later and I tell you or you watch it and you tell me okay thanks for a real nice presentation cool thank you glad to hear that so see you in an hour right okay okay okay thank you for reminding me about repeating the mistakes I always forget and keeping the time cool then see you in a minute okay so we are the next yes what's your name Matej because in Portuguese we say matej we play matej in Czech thank you thank you for the explanation you can use this one here you can do you can prepare atmi or bj it's up to you but there is atmi we use atmi there is idon't condition somewhere yeah here thank you disable wait and please repeat the question okay because of recording and we will show you like 10 minutes before the end like it's 10 minutes sign here