Michal Kordas — Groovier BDD with Spock

why you for me it’s like 5:30 a.m. so sounds like a good time for start welcome everyone I mean me how gorgeous I came to you from Krakow Poland and I work in luck soft as a keyway but my main role is not to test the quality into the software at some late stage of software development it’s rather to build quality into entire process as I believe that software with really good quality doesn’t emerge after like sufficient amount of testing rather it needs to be built with the quality from the very beginning so having great requirements having great code that is maintainable that is readable then having proper release and deployment processes and proper feedback loops working all the time getting gazanova whether what we call it actually works properly and today I’m gonna talk about three topics BDD groovy and Spock so enough chitchat and let’s go into the things that’s a typical Apple product white cover one button and people sleeping on the streets in front of high stores just begging to get a new iPhone just after releasing this is typical Google product one text field one button and billions of queries every day billions of dollars of revenue every month and this is how our products look like mass complexity a lot of strange things going on and that’s that’s our daily life but is it rocket science we in fact are usually not sending any rockets to the moon yeah so our applications usually are just business applications that do some logic and they are not really complicated so there are not hard core while on the other hand we all know that picture I do not need to describe that what is inside we all have some miscommunications problems some things happen that that we do not deliver what is real in ears it appears that the only real problem the only challenge in our software are not that technology problems because we are smart guys we can use whatever technology we like we can really do really great things with software but what challenges us is to understand properly well what we are trying to solve in order to create software that matters first of all we need to see us reaching the goals we need to understand order the purposes of the things we’re doing what are the goals what are the aims and these are the things that business people are good about so they see the whole picture of the things and they’re floating somewhere between the skies and space and for us those guys are strange creatures what we’re talking about but ultimately our current work our tasks do not matter much without those goals so we need to somehow find a way how to convey in what we do those things so that what we create is really used is just muttering for someone and how we can quarantine that what we do is find verification and university the great verification tool for me was Java C – yeah so it compiled it works it is ready to be shown into lecture but we are all responsible guys and we test our software yeah otherwise you wouldn’t be on that conference we know that testing crucial compiling is not enough to verify that what we how that works so we do unit testing but that’s just basic verification the more advanced technique

is to do test first approach where we begin with verification for our code and our code is just written to fulfill that verification so that our feedback loop is really fast actual it’s negative so we write the code and immediately we know whether it is alright or not because our tests lead us in the proper direction and even next step is TDD and what’s the difference between TDD and test first it’s pretty crucial because in tests first our tests lead the code creation while in TDD our test leads code creation of course but they also lead the design because in DD D we have refactoring stage which is very often forgotten and then it there is no difference between test verse and TV but in TDD there’s a lot of pressure on heavy refactoring average cycle where our design emerges so the first unit testing framework was as unit for small talk but small talk was quickly forgotten in the industry and it was replaced by J unit CPP unit PHP unit and all the xunit frameworks and outside of this framework did one but think they have you need in their name and they kind of suggest that you should do unit testing that TDD is about unit testing but originally the idea of TDD was testing not unit testing and that’s a huge difference because expert for gramming was from the very beginning about acceptance test customer collaboration and so on so this unit kind of misleads us to the direction thinking about technical tests but it’s not limited to it and at some point of time done North had to come and say come on guys you are not doing TV the proper way this high-level tests are also important and that they were in the nature of TDD but this was spoiled by this J Union say action is where we fought about only in retesting and you should have the broader scope and think also about all levels all kinds of tests so tests not unit tests and the North said that of course the specification we write things to be understandable for developers and that’s pretty obvious because we are smart but in what we do and we understand what non-technical people tell to us but the second point is much more challenging so the north notice that what we say also needs to be understand able to non-technical people and that’s that’s a must to have this magic happening between those two words I would say and specification of course should be unambiguous for both sides and they should be run ready frequency because we want our what we do to work not only right now but all the time now in the in the future the North proposed to use Kirkland language and gherkin language you may know that word from London if you are traveler this is Gorky mean in City of London or if you’d like more Slavic climates this is Kirk in India and what it is it is just language consisting of three main keywords given where we set the state of the world we like least our preconditions for our specifications then we have one step where actual behavior happens we’re still most the system happens and and in that then we expect some results basically we perform assertions there to verify that what we tested works fine the North the north also proposed JB hey framer so he came with ready solution for those higher-level tests and in short Jay behaved is composed of three parts a plaintext description of what we expect from from our ups it’s just scenario title given when steps and pretty important part that is that is also missed from time to time is narrative where we talk about why’s yeah so those things are about what’s and house yeah and it was also forgotten in originally you need that no one was mashing why why we want some behavior to happen why it is important for someone water benefits and and these are those

proposals that we’re talking about we need to have them visible so that we are on the same page these are the things that we are doing right now and this is our goal we need to have a goal to have a success the next part is Java code that is binding between those plaintext scenarios and Java code so so the main difference between j-unit and JE behave is that in j-unit we drive test execution by test metals in j behave we drive test execution by this plain text file but underneath these are those Java metals so each line from this file is taken and proper line corresponding line is is font in Java code and executed so this plain text file step by step drives execution off of the story file and underneath it is just plain j-unit so there is no much difference you can use J behave as a replacement for J unit you can mix them together that’s pretty convenient and we also need to configure J behave and that’s the bad part a nasty part usually that much of conversion is needed to make it working and if you try to Google how to do it and every page will tell you to do it differently so there is no one unified way internal it’s very configurable but that’s that’s not a nice thing to do us as you need to go deeply into the things how do you behave forced to make it working properly but at least it’s just once you do it once for an entire project and you are done looks like Jake behaves pretty cool framework when I joined like soft I notice that they use a lot of it and they are proud of it yeah we’re using the behavior trendy we are following BDD principles and that’s that’s great so then I start talking with people about this and I was pretty excited yeah okay you do it you should be happy and so on well in fact the developers in in the teams I was working with they were not really into the things so they considered J behaviors pretty terrible thing so I’ve never met a developer doubt that was happy okay today I am gonna write some J behaves it was rather last task that was postponed that was like left on the whiteboard for a long time because no one wanted to take it as it was not pleasant for those guys so then I started asking many questions why you don’t like this cutting-edge technology was created by the more friend you have it on in your CV and you’re proud of it yes what’s wrong with it and I started collecting the reasons kind of pins that were going and then making J behave not so good solution and first reason was that whenever our developer needs to work on those they have two separate files so ideally they would need to go into split view and modify both files at the same time so and changing one file impacts the in another file so it’s not convenient just to switch between those and work on the scenarios so that because these files are very tightly coupled so changing some characters in one file forces you to change things in the other then ostrov of opers you probably use IntelliJ and you press shift F 630 of amia through to change names of your methods classes whatever so if you try to press shift of six in J behave it doesn’t work even with the plugin for IntelliJ and that’s not what we like we like smart things we liked factoring three we don’t want to do those things manually then with J behave the huge overhead is connected because we need to maintain those two files and it doesn’t make sense to use J behavior lower levels as testing parameter says that we should have small amount of system level tests and lot of unit tests so if you have to write a lot of unit tests in J behave this would take majority of your time and you wouldn’t write that much code you would be just writing scenarios so that’s that’s why this this is suited mainly for system level we have low amount of them so up to hundreds but if you have to write thousands of those it be too much to handle then those story follows at some point where we start to describe not only the main centers in our system but all the cases all the like different things that may happen in our complex systems they

start to look pretty dull so probably you don’t see much what is going on here and that’s on purpose because that’s how they start to look for the people whenever they contain more information more scenarios more narratives it’s all become blurred and not visible not readable another pin that goes into J behave are those parameter converters so the plain text file description doesn’t know anything about types and Java is strongly typed language so whenever we have parameters windows they behave we pass some parameters to our notice they need to be converted into type safe objects in Java in order to do that we need to have parameter converters and this is the sample how to convert true and false into the proper boolean objects a lot of boilerplate code just to do some simple things like convert true and falls to the Java’s – and false so at some point it also becomes pain to provide such converters for every type of object we may have then whenever we parameterize those scenarios under the hood those parameters are replaced by dot star so redirects marcher and those steps are like marched by reg X so you need to have records process of running your mind all the time in order to understand well how those storing files much to Java code so at some point also becomes risky and this greedy matter may not be as intuitive as you may imagine so at some point we notice that only developers written those story files and we made an experiment we set ok to our analysts please provide for for us those specifications and it was working for some time but then we realize that those analysts use to reach language so they wrote beautiful story files with this description how the our ups should work but those beautiful descriptions were not corresponding to the testing framework that much because we either needed to write the same step many times because they use different words for the same status as this was better English sentence all we needed to have many aliases yes so the same thing like send message was written in many many different ways to have the proper sound in English so so we need to find it so we had huge complexity just connected with those analysts language it appeared to be more efficient just to delegate it to developers so developers understood what is the existing framework what are the steps available what are the consequences if we try to increase the complexity of of it because it’s all the code underneath ear so if they understand well what’s the underneath they could propose steps that we easily to automate in that framework but of course those that workers dislike it that was not the stuff they wanted to do and the biggest failure in our case was that those business people were not reading the story files at some point because they were dull because they were complex because we had too many of them and we didn’t find a way how to convince them that this will give some benefits so instead of reading those they were calling us talking with us they find it more convenient so the original idea of those PDD and collaboration by automated high-level tests was broken and they appeared the tool designed for non developers were used only by developers definitely was something wrong with it we did huge overhead from nothing at at some point my teams and even me started to think that BDD tools are crap yeah they do not bring anything considering all the above so what we can do at that point yeah you use it and and suffer or maybe have some other ideas so the first idea that that was proposed by many people in my team is to abandon jbf yeah as only developers right those scenarios as they are read only by developers why not use jail it generate this language of developers we can perfectly fine use day you need to describe system behavior if this part you need in their name so this Sutter’s unit testing but we can use dream into whatever test we like of

course the unit has this camelcase but as tougher developers we are very proficient in reading comic eyes we could have a books in comic eyes and it would be no problem for us as we we are good in that we can even have comments if you really if you really want to have those given one then we can have it in Jaime tests and then proceed that’s perfectly fine if we don’t like comments we can even name methods appropriately so given something when something then something and this is pretty much equivalent to J behave that is just a code we don’t have these two files just it’s one file and then developer should love it because every factor rings work here many things stuff that they use every day is is here like us know in normal unit us so this would be example of the nice Jerry test and I chose parameterize test and this test scripts vending machine so it tests verifies whether if we insert some particular college to the vending machine the month the credit display this is the proper so what we have here is that we have these parameters metal parameters that return collection of array of objects then we declare two dimensional object array then we instantiate three dimensional array of bills where we provide two-dimensional array of two dollars and two-dimensional array of five dollars and $10 here as we like imitability in Java we return an immutable list of it to the test we everywhere have final our keywords also for readability purposes we have pretty nice name with should do something when something happens notation we use hunk rest matter which actually really well explains our assertion so we threw in circuit credit something is equal to expect the result pretty expressive way of making assertion and you may think that’s beautiful and then you would be in the county that of people that are spoiled by j-unit you think that it is nice and readable and beautiful then you are the camp of people dub are totally spoiled by job or you may think otherwise that if you are virgins kind of not spoiled by Java and you are free you have fresh mind you will see that this is pure noise amount of information in this test is less than 40 30% and the other things are just keywords here some some language decoration and I don’t know what happened like my presentation disappeared right now so I need some help maybe it was disconnected ok now it works ok so let’s go back to this test and in fact the decent amount of like business knowledge converting that then test is just it yeah so given vending machine he finds insert two dollars then I have two dollars credit if I insert five and then I have fifteen dollars of credit so compare this to this one and this is exactly the same injury unit so the signal to noise ratio is huge to make think wars such the unit tests are really set especially if you use Comcast matters you might notice it in your test yeah it’s it is really self so what we can do what we can do with that either go to J unit and beam jungle of those noise just G behave which we already spoke about and it has many of problems with it or maybe there is a fourth way and I like to introduce groovy language which would be helpful to discover the third way that I want to talk about today groovy is dynamic language so some people when they see it’s dynamic they run away immediately they like Scala Java which are strongly statically typed and they don’t want to hear about anything else but in fact groovy can be statically typed checked if needed so we can decide whether we want it safe or it’s not necessary that next so it is optionally optionally typed and strongly type at the same time you may think okay that’s mistake in my slide it’s contradiction language cannot be optional it I’ve been strongly typed

these are two distinct things but in to understand it we need to see the difference what does strongly and what does statically mean so let’s take java where if we try to divide one by string two of course it doesn’t compile we get compiler error just operands are not compatible with each other it’s obvious mistake then if we take C++ may noticed that types are not not strictly bound to their objects so we can cast for example strings to some pointer to integers then we can extract it and do the division and this will compile so C++ is statically typed but not strongly typed we can change the type of the things during runtime then you have JavaScript and what’s the answer what the output of this in JavaScript do you have idea three I would say this is integer integer and this is half so it’s pretty into advance for half also javascript can do this division nicely and just provide sounds for half so that’s the problem with JavaScript no one knows what it will be the rules are so tricky that’s why javascript is dynamically typed and and definitely it’s not strongly typed so we can cost between everything and it all happens in the run time and then we have groovy which can be dynamically typed so it won’t prevent us from compiling this code yes we can try dividing integer by string and by default it will start running but IntelliJ before before running will would warn us yeah we you are trying to do some very stupid things you are trying to divide integer by string and most likely to fight during runtime so are you sure about it so if you ignore these warnings it’s kind of up to you if you take this risk if you don’t want to have such problems just do not ignore warnings well if we want to have like full type safety if you won’t stop people from doing such mistakes if we do not trust them that they will keep those things then we can annotate with type checked and then it will behave exactly the same as in Java it would just doesn’t compile then in groovy is created to work with job so you will be groovy developers just after this talk because the only thing needed to start coding groovy is to know that 99% of Java code is valid groovy code so you can just rename your file from Java to groovy at Java and the groovy compiler to your build tool and you will start groovy as this groovy specific things could be introduced over the time you don’t need to start with those we can write Java first and then learn a thing by thinkand and introduce those to your code then we have many useful things that are painful for Java developers I won’t go into the details you can read about what cool features groovy has in addition to Java that simplify the coding it has not raw syntax for maps and lists which is missing in Java and even they said that in Java 9 there won’t be such syntax there will be some static factory methods for maps and lists that are immutable but you won’t ever get such syntax in Java and groovy has it it’s pretty natural one we have math that is precise so no more a zero nine nine nine nine eight answers from simple subtraction three divided by two is one and half not one as in Java primitives don’t exist so groov is more object-oriented language so one that class simple name returns just integer in Java writers it wouldn’t compile so there are many additions to the language that that makes it more cool and most importantly for our proposals are that syntax is optional many this syntax that was seen in that this.j unit test could be totally skipped in in groovy they made it optional so you can use it but you can omit it so semicolons are optional when parameters are provided to the method calls parentheses can be can be skipped as it is unambiguous that you

want to just call this method with those parameters and even dots could be skipped when metals are changed and in result these could provide us sentences like English readable sentences without any additional syntax that that is stopping us to read those exactly as as it was plain English so if we order coffee and with milk and sugar you could write it without parentheses here without dots justice combined it’s to be there but this is also a comma that we proper punctuation in English so we get those nice results for example we can check that groove is readable in veritable way so here we provide the map of parameters so this would be the map syntax so we provide two metal check parameter there as parameter map that has key dot and groovy as a value then then we can chain methods method is then readable again proper English sentence then I can speak to jailbreak saying groove is awesome also in this very day way with the proper punctuation can you see it that’s valid groovy code that there that would be the Java one Java version and this is just groovy much much better much clearer in this neurosis is limited very much and then we have spoke framework that is just built based on the groovy it leverages all the features that groovy brings to us and it can be used to test any JVM application we wish so most importantly Java once already it’s in version one dot and so it’s out of button and you may wonder why’s pop name and pattern it is our outer of those frameworks as it is just connection of speck and mock and it doesn’t have anything with this guy so it’s just coincidence first of all what Spock does is redefines the language so we do not never speak about system under test we rather speak about system under specification so there are no more tests in spoke those are specs it has all the features of groovy it is really easy to learn Simon Simon’s groovy because it is based on j-unit so if you know Jarrett it’s just different syntax more powerful things but underneath it’s just the same and there are no special API so no special API for mocking no special API for assertions everything is based on operators moreover we don’t need to provide any annotations as engineer it so there are very good defaults that they just take the class with methods and and that those are interpreted as tests without any additional annotations we have very detailed failure information so we get full context what exactly went wrong so it’s not only information that in this case even a surgery the cool assertion framework would tell us that free was not equal to – that’s the only information that could assert a provide us if you just assert true from the generative tell us that true – was not equal to false so these those assertions provide a very poor context while Spock takes entire line and then it displays to string of every participating object in the assertion and displays that the evaluated value of that expression then spoke puts a lot of focus on specific end behavior so it’s its entire new testing language where this amount of additional things that the front decoration is minimized so we can focus on what we want to verify not on all the other things around and it’s suitable for all kinds of testing so I was talking TDD and BDD and generally idea of g-unit and extreme programming was not about unit testing it is about all kinds of testing so TDD BDD unit integration tests last us first component system acceptance all of that can be done in spoke without any additional dependencies so when I see dependencies in the modules of products I work with I see the huge list of hamcrest sergej GU needs mockito cut exception and so on well we could have just groovy and spoke and that’s it what we need for

all kinds of testing really don’t need anything else and this is how it looks so we have class that is name of specification and it needs to extend specification base class for our for our our each test then our feature methods are our tests yeah where we execute the scenario and we could provide any name for those scenarios so it could be any Unicode name which is huge advantage over Jamie because we don’t need to encode hours and hours into comma case we can provide the natural name for four rows now I have a quiz for you does it compile in Java it is valid Java code some people say yes majority is not convinced that it compiles so maybe this would help this is screenshot from IntelliJ and we have warning here saying that it is unused label and other labels these are forgotten Java feature that that is kind of go Java go-to statement that enables us to escape from the loops so if we put a label and it is not used it would warn us but it is language feature that spoke frame of really leverages and of course this is just common yeah does double stars are good comments of this is ignored and that’s why it compiles but Spock uses dos just to indicate the section in that test so we put given : and their things there have different semantics they are setup code when then and where are just parameterize ations for the tests which are optional and we can also make it shorter with expect yeah so when then could we make into expect step where we do both actions and assertions we could use spoke for data-driven testing us the tables the tables known from Jay behaved to parametrize our tests are like native for the Spock so you might think how the hell it compiles and in fact this is valid groovy cuts a groove is so powerful that this is this is valid code and these are just binary ORS yes and spoke interprets it as a table and provides those parameters into that metals so a lot of groovy magic used here so in fact it is specific language for spoke just to run the tests so it’s code that has very special meaning but still it is code so all the refactorings all the nice things we like from ideas work there it can also provide they this parameters in the method names it’s called unrolling where we could parameterize our test names with with some parameters that were provided so it enables us to see on continuous integrations that if something fails it was involved with those parameters and it felt because of it so we have very detailed failure information so this is huge advantage over the classical Java testing frameworks and we have mocking mocking API that is based just on operators so I won’t go into details here but for examples the spoke uses the proper test double conventions unlike mojito we have for example stop that it’s meant just very cold up in mock eat everything is mock well here we have the proper distinction and we record mocks we say about cardinality of method calls we say about method constraint just using operators so that’s that’s really great how it works and you may like it or not like it but it’s pretty powerful so I recommend you going into that stuff and then spoke really like helps us to provide also variable titles for our specs so we could have a notation saying this is easier to read than comic ice name of the class you can annotate things with subject meaning that wait this will be tested in the specification we could have narratives that are annotations and multi-line strings that enables us just put more wise into each test not only this higher level test but we could put those also a unit test which you may find also really valuable for a product then we have additional notation is reducing Spock wandered all like issue OC just for battle traceability we have test first support unlike gene you can annotate noted implemented and then it would pass only if it fails so whenever

we implant something it’s it means that it notifies us that we are done and this notation should be removed unlike ignore injury read that we may forget and leave it always ignored then we could very easily test the failure conditions with all additional libraries it’s just thrown a syntax so we’ll make assertion bye-bye from keyboard and provide the class name and it works out of the box we can also have textual descriptions so each step can have string that describes in business language what this test is supposed to detect and those who could connect with the J behave lines of its plain text so we could transfer those J behave descriptions from from a separate file into the same file and those would be just strings that are placed after the levels and so at this point we may totally resign from J behave and have a say have the equivalent where the code is just underneath those plain text specifications and we can have free ports out of that so I found two open source libraries that generates pretty nice reports out of those descriptions so what those reports do are just taking away the code and they’re living just this guy’s juicy business language from those tests and they present it to anyone who is willing to annoy those then we can even generate are down from those if you like it cup pages and want to have it presented in nice way we could use those and if we want to use even more smart away if we don’t want to duplicate ourselves you could try to write the code in more readable way so instead of providing these textual descriptions you could write our code in the way it is self explanatory and so here in this example I am trying to use code that uses this optional syntax just to make it almost like a language also for example system method receives and the parameter message but as it is without this parentheses without semicolons it is pretty readable so even non-technical people could have a clue what this test is about at this point and at some point we notice that we could events even more so we invited our own domain-specific language just to make those tests look exactly like they were written and J behave so this this the previous level is pretty similar but it still be technical yes we have some method invocation we have some dots it’s it looks technical but then we managed to convert it into those and this is still groovy that looks exactly like J behave so here are the assertion and this is series of methods calls chaining and method parameters and underneath there is domain-specific language that just interprets each of the line with the type safety and execute those and we don’t have any application within that way of specifying things and this is how it looks in the real life in IntelliJ so we have parameters to the methods and surgeons would be shown when the failure happens so if the report status was different than and would have great insight into what was wrong and this this is how it was in J behave yeah so this is J behave 10th X and this is valued Ravi code very very similar but this gives much more possibilities like for example static analysis that could be used because this is just a code every kind of refactoring Walzer out-of-the-box in IntelliJ and lot of fun so our droppers at this point started to love writing specifications as they have a lot of fun with creating their own DSL they were writing code not plain text and actually started to really live at this point then we took those specifications with narrative with titles with nice like proper sentences describing what is tested there and we start to generate reports so such spoke test was just converted into confluence page in our case for analysts the confluence was used for communication and we were generating out of our test shoot confluence pages with the current description of the system

that would never lie and this was the the clue here to make this magic happening between analysts and us so we started to notice that what they missed in G behave was nice formatting colors kind of possibility to extend some part here some moving elements here and and nice syntax coloring so the colors were the clue to to communication so those are simple people those analyses and they’d like some some beautiful layout and they started to ask the questions about this they started to really work with us and I really noticed that the BDD started working for us really really well so it is possible it is possible definitely to introduce that in product which requires just some smart way of presenting attends and we and everyone is to like it yeah that’s that’s a thing both sides so a couple of thoughts to finish do not let intent to be lost in translation so whenever you have possibility to decrease amount of layers in your tests just just remove some layer so as we did in JB have we didn’t have this additional layer of plain text and glue code we just have pure like domain-specific language in that was executed then these cells don’t need to be widely acceptable so you can create your own domain-specific languages for your own purposes and it doesn’t need to be anything special or given from outside you can be outer of your own and you can create living specifications even if you developers or qsu are doing it you don’t need to write those by analysts in order to make it living and please leverage the goodness of the tools because the tools are this day is really smart magic and they help with lot of things so why start with J meat from 90s let’s use Spock that give so much possibilities just not forget that the products may succeed despite very bad tools so when you’ve used a unit for everything you may still have super successful product and you may fail totally infer project even if you spot or any kind of be digital yeah and the most important testing to see is your mind so keep it in our minds thanks a lot and now have time for questions right understand is developed and supported by the loksat no it was not developed by like soft it was developed as open-source project by Qatar neither governments or sport yes and I have some questions what companies use now in production this mmm listen I think a lot of companies it’s too hard to enumerate but every some week you can name no I don’t think the companies like explicit state because it is not in production this is testing tool yeah but whenever the volpin team wants to test things in spot they come in some big projects where it’s used for testing so I don’t know anything outside the laksa but I know that it’s heavily used in like soft in our teams like many teams use it and they are happy next question about performance do you measure performance in comparison with yes so we have test use water system level test so the time needed to execute the test itself is usually like small fraction of the time you to execute entire test because this tests are executed entire system end-to-end yeah so usually those and when stars that are just sending some messages some calls and they are expecting answers so the the performance is pretty comparable outside maybe there is something is I know 50 percent faster or slower but it doesn’t matter to the overall performance as those tests are supposed to be end to end and if you mean unit tests yes Spock has over had over J unit so it is slower than Jared but it is still not like 100 times 5 so err maybe up to 10 10 times slower but the test itself yeah the code test and underneath it’s it’s another thing yeah so if you have tests that are lasting I know five milliseconds yeah so if you take the test that is last thing I know thousandth microseconds here so it

doesn’t really matter of thousand yes maybe there are bit bits like slower but we haven’t found it an issue or something appropriate and is it online integration or source files and manual insert yes this good question because I haven’t spoke about it so we heard for half a day and we wrote our custom converter that was suited to convert our custom tests so it’s not open source we did it for our purposes very quickly and the results were were great because it was suited for our needs so we just took the spoke files and we’ve thrown away those of the syntax that still remains in those spoke files then we formatted well and we uploaded to our confluence so it was 100 lines script so we haven’t published anywhere but you can write your own that’s the super easy actually no magic there but if you want some proper solution those I showed your those reports and the reports also can generate any syntax you like because they work on templates yeah so you can have confluence template or markdown template or PDF template whatever you want and you can just specify what we are interested to see in those reports and publish it so there are open source libraries just to write reports out of spoke yes