Testing Microservices

we're going to talk again about microservices trend that we're experiencing and now we're going to focus on what how to test it so please welcome casually in thank you very much so hello everyone today I'm going to be talking about testing microservices and I'm really pleased that there's so many of you here today clearly excited about testing because I really think it's an area that can be kind of forgotten or left until later and I think it's really important so first a quick introduction my name is Katherine Stanley or I'm generally known as Kate and I'm a software engineer working IBM on WebSphere application server Liberty I've been there for about 18 months and so far I'm really really enjoying it and it's allowed me to come in to exciting things like coming to speak to you today there's a link there to github where I have all my github account and Twitter as well so I've been tweeting about the things I've been up to at Jay focus so if I've really enjoyed it so onto the agenda for this talk I'm first going to cover some background about why I'm here today and why I'm going to talk about testing micro services and kind of my experiences that I've had so forth so far to explain to you why I've kind of formed the views I'm going to share with you today I'm then going to go on to talk about what are micro services there's been quite a lots of talks about micro services at this conference so hopefully most of you have got the basics down but I'm just going to do a couple of slides just as a refresh in case some of you have been avoiding the micro services talks or want to refresh I'm then going to introduce an example application architecture so throughout this talk I'm going to use an example application as kind of a framework to discuss testing micro services and highlight why you need the different testing strategies so I'll introduce that and then move on to talking about the different testing strategies and then the final piece will be covering evolving a monolith application into micro service application and although all of the testing strategies I'm going to cover apply to any micro service application there are perhaps some extra things that you need to consider when you're looking at specifically evolving your monolithic application and some sort of testing considerations as you go through that journey and then a conclusion so let me introduce you to the Liberty starter which is the example application that I'm going to use it's a tool that I've been working on with my team back in the UK and it's a tool just to get people started with writing Java applications and more specifically writing Java EE applications on Liberty we found that particularly when you're moving to micro services you have to write a lot of the build code and configuration before you can start writing your actual application like the meet a bit so the Liberty starter just gets you to the point of writing your app your application code much more quickly there's a set of technology options to choose from and when you select them you then download a zip file which has an application sort of pre-configured inside that you can build and run using maven and it will compile your code run some tests and start your application and it also has configurations specific to the technologies that you've just selected so if you select rest or you select spring boot with spring MVC it will put in the maven dependencies that you need so you don't have to go and edit or maven file add all your dependencies you can just get started and the reason that I'm using this application is because we started building it to help people and we thought great we'll just build it and we bought it as a monolithic application but then once we kind of got the beginning of out there people started saying well this is really cool we want to add new technologies and we thought actually if we keep it within our team and it's just our team that owns it we're going to get to a point where there's so many different technology types that we're having to go talk to the people who know about spring boot or talk to the people who know about rest and then come back and us manage this massive monolith so we thought actually moving to microservices would help us manage the application better so we decided to have that a piece of the application a service for us to own and then have technology pieces for other teams to own so my talk today is kind of going to cover the things we found as we've moved to micro services the things we found now that we're kind of there and looking at what testing we should be doing to make sure we're happy with our application and I'm going to kind of combine that with some of the things that are already out there in terms of information about testing micro services although given the amount of information we've had today about micro services there's actually in comparison not too much out there about testing micro services so I really think it's an area that we can kind of improve upon and look more into so what's out of scope for this presentation I do only have 50 minutes and I feel like testing to completely test an application you could kind of go on for a long time so I'm not going to cover any sort of performance testing or testing scalability or security testing or monitoring I'm kind of looking at what we as developers looked at as we were writing our application and how we were kind of going along we used test-driven development so it was kind of the tests that we had to write in order to write our application so that's kind of what I'm going to cover so before we get into talking about the actual testing I'll do a quick overview of what are micro services and the kind of key points that maybe you can take away from all your many talks over the last day or so so a micro service is an application that is then split down into different services and each service has to have a specific role or function and that's how you work out how to split it down the services communicate over language agnostic protocol for example rest or you could use other language agnostic protocols such as WebSockets or other messaging services and the nice thing about this is that then because it's language agnostic you can write your different services in different languages and I guess for us looking at what we're creating that was something that was going to be really valuable because if a different team and outside of Liberty wants to come along and write something for us then they can do it in whatever language they want to they have to stick to Java and finally the service should be independently deployable so whereas with our monolithic application everything is deployed on the one server in the one doc of a file or whatever now you have the pieces all deployed separately and there are some great things that come out of moving to micro services you might want to move to get more rapid delivery because now that you can push the different pieces independently you can iterate through the pieces separately so if one team finishes something that it have to wait for everyone else to be finished before you get the new code out to better use scaling resources so again because it's broken down you can scale one piece rather than scaling the whole application and that save you a lot of resource and also to move pieces to the cloud which is kind of an angle that perhaps isn't touched not as much but it might be that actually you want to manage your application slightly differently like we did or there's a piece that you don't really want to have to deploy on your own resources and you want someone else to put it on the cloud somewhere so that's an option that's a good reason to move to micro services too but there are some considerations it's not a silver bullet it's not going to solve all your problems straight away necessarily because you have all of these new pieces they may be simple in themselves but you have increased point overhead because now you have to deploy four or five or six pieces you have increased complexity because now you have all of the plumbing between all your pieces so although the individual services could be really simple there's complexity in the way they connect together and we'll find that actually some of the testing is really focusing on that change and also I thought I couldn't not mention this but your testing strategy you might have to change so that's another piece that perhaps you hadn't really considered before that actually you might need to go back and rethink some of the ways you do testing and the order in which you test in your build pipeline for example so now that I've given you a quick overview of microservices we can go straight into looking at our sample micro service in a bit more detail so that we can look at the testing strategies in comparison so this is the sample micro service and asked me that I've kind of shown and the dotted gray line around the outside is the whole application and then we have blue boxes which I've put to indicate the different services so you can see there we have the zip service that I mentioned earlier and that's the service that my team would own for example and then we have some amount of tech services in the current version of the Liberty starter on bluemix I think there's six and I've only put three here because what we're going to focus on today is the internals of the zip service each of the different services would probably have quite similar internals and you would have to test them all in a similar way so for today I'll just focus on the zip service but keep in mind that you would still have to test all your other services in the same way so this is sort of a deeper dive into how our Anatomy looks and is perhaps a bit simplified but we've got at the top we've got where the user accesses the service through an API gateway so that would be sort of where the front end lives we've got some domain logic which is what's actually building up our zip file and data connector which calls out to a database and in this case the database is holding a list of the services that are available so this could be your service registry for our application at the moment we have a list in a database that we sort of update when the services come and go and the service connector which is the piece that's calling out to the individual tech services and hopefully you'll see why I've broken it down in this way as we go through the different testing strategies so onto the testing jeez I'm going to cover five different strategies and some of these names are probably familiar to do to you if you've been testing monolithic applications but hopefully by the end of this talk you'll kind of see where each of them could be thought of slightly differently in the micro service environment and where you might have to make a few tweaks so we'll start with unit testing so typically unit testing is testing a small piece of behavior usually at the class level but if there's several classes a closely linked it could be slightly wider and if you're using test-driven development like we were then that drives your implementation which can be quite a useful tool for making sure you write your application in a nice organized way and there are two types I'm going to highlight evoke sort of methods to unit test and that's blackbox testing or test doubles and when I did a practice this presentation the name test doubles kind of raised a few questions and this is sort of a generic term for any object that you create just for the test run you don't put it into production often they're called mocks or mock is a type of test level so blackbox testing this where you would use the actual object and treat the unit as a black box so you call into the unit and see what your response is you don't put any sort of framework around it it's useful for testing domain logic that's highly state based because if you have a lot of moving parts around your unit then perhaps putting in extra framework or test doubles will not give you consistent results and perhaps give you a false view of how your system is doing the example in our application where we could use this is to test the sort of base project construction and what I mean by this is that when we build a posit for we have to start off with the pieces that are common across everything so no matter which technology you select we still want to give you a maven build strip that gives you an completion of your code and gives you testing and everything and there's certain testing dependencies as well like you might we might say okay we think your ways in some form of test dependency so have je in it so that's kind of the piece in it in here that we would have for our and then the second piece which is kind of what we use more and you could use both of these or just one or the other it's kind of up to you but we use test doubles most which was to create a test double to isolate your individual unit and this is useful if you've got a routing layer and you're just looking at are the requests being routed to the right places because you can just create a test double but reflects what you expect to happen and for gateway and repository testing if you're checking that the messages are really being passed around in the right way and I've got an example here of how we did this so this is a stub service connector and so it's not a market system so it just implements a couple of different classes so you'll see up here we have just two methods that we've kind of made versions of and what they're doing is just passing back sort pre-canned responses it's not in the actual production system the service connector would call out to our services and go get some information in this case we're just returning something pre-configured that is kind of a stub of what we would actually have and this is one of our example test classes so this is just using j-unit so in maven we just declared j-unit as one of our dependencies and here you can see that we're testing a class called the dependency handler and all the dependency handler is doing is grabbing dependencies of maven dependencies and it's kind of storing them in a certain way to pass onto another piece which is building up our zip file and the reason that in this case stubs are very useful is because we can create a stub service connector and pass that to the dependency handler and we've set it up so that the dependency handled the only thing it calls that then calls certainly is our service connector so once we have a stub version of it we can then completely unit test our dependency handler without worrying about other state changes affecting what's going on because we know all the calls come to our stub service connector such as a quick example for you so so far unit testing perhaps looking pretty similar to how you would do it in a monolithic application so what are the things to consider when you're in a micro service application well although it's not true that micro services have to be small it certainly is true that people when they move micro services often find that their services can be quite small and it depends on the function involved but you could find that you have a lot very small services and actually find that your complexity moves from being in your service to in the plumbing the actual units could be doing very little and the real complexity is and how you pass between the different pieces and when this is the case you have to kind of look back and think about are my unit tests really giving me that much you always want perhaps some unit tests but it might be the unit testing isn't the way to go if your individual units aren't doing any complex logic at all and you also find the because you're then passing lots of pieces around whereas in my example a minute ago I said you know we were just calling out to one different class so we only had to have one stub if it's calling out all over the place and you have to create many different mocks and then if someone comes along a change is something you have to go around and update them all and then that kind of leaves you open to people being perhaps a bit lazy and not dating them quite the way they should and then you end up with tests that aren't really testing what you thought they were so there's definitely a trade-off between the time to maintain the framework and the different test doubles for your unit tests and the usefulness that you're getting from a test suite so you should really look at making it small and focused as possible and actually in some cases perhaps unit tests aren't the most useful but you should instead look at component testing which I will cover next so a component test is again perhaps a phrase you've heard before it tests a portion of the system and this component should be a replaceable piece of the system so in a micro-service world this leads quite naturally to a component being a service and you can just have a one-to-one mapping between your components and your services I'm going to cover two options for testing these components the first is altering the internals of your component or your service and the second is creating a test service so altering the internals by this I mean creating an internal interface inside your unit that you hit during testing but not in production so you don't touch the network in this case and you instead of route your calls into this interface that means you don't have to make any calls out to anywhere else and you really do test your one little component this is really good because it gives you fast execution and you're not having to start the per service you can get really quick responses to find out did the change I just made break anything did it fix what I was trying to fix it gives you a fast turnover but there are things to consider it does mean you're then mixing your application code in your test code in together and you perhaps have to think carefully about how you then put it into production to make sure in production you're hitting the right classes but also it could mean that you miss things so if you've got a class that you're calling into only in the test case then there's probably some other class you're not calling in your test case so what happens in production is it working that's kind of the the two things you have to consider so what we did for our system and what worked very well given the structure that we have is to have a test service so here I am just talking about me personally testing my zip service I'm not worrying too much about the people who own the different tech services in my opinion they should test their own services so for my particular service I can say well I know that each of the services I'm going to call - we'll look roughly the same we're going to ask them for similar things and then we're going to return us broadly similar things so actually creating a test service that does everything that we might expect from someone else is a really good option and it means that the complexity is then contained within the test service rather than in your application and it kind of gives you that nice separation and it also thoroughly test your network calls so the way we set it up in our application is we have our test service start up and we access it via rest requests in exactly the same way that we would all our other services we don't call it directly we just go by rest so we really are testing the network calls the downside is that obviously you're now starting up a server to run these tests you don't get that fast feedback if there's the increased execution time so how did we do this in our application so I mentioned earlier that the payload you get from the Liberty starter is and gives you maven built code for our particular application we're actually building it using Gradle there was a combination of different people in the team's having different opinions and the fact that we thought it'd be nice to kind of learn both so we have Gradle for our actual application and what you can do in Gradle is write your own groovy files that then create sort custom tasks and in liberty you can create a server to Mpho which is just a file that contains environment variables for your server so what we do is we just have a custom Gradle task that if a property is set it creates the server dem file with the properties you specified so the top piece here is our groovy file and then the bottom piece is aligned in a Gradle build file so that's our main build file that says I want you to put the location here and what we do is we run ad server and just before we run the tests and then we run remove sub and which I haven't shown here after we fund the tests so then by the time it gets to packaging our application the server 2m5 is that and we don't worry about packaging environment variables that cause errors and then in the production we can just set up a new environment variable that tells us where our database actually lives and where you should go to find the services that are available so I'm now going to move on to talk about contract testing so far with unit and component testing I'd say these things you've probably done quite a bit for in monolithic applications whereas contract testing is perhaps something that you wouldn't have had to consider as much before so here by contract I'm defining this to be an agreed set of input and output attributes and contract tests simply test that the inputs and outputs have those particular attributes you're not checking for behavior that happens once you get the attributes or anything it's just are you expecting the right attributes and are you giving out once you say you're going to get out and it's testing the boundaries between your different applications and your external services so in this diagram I have four little red circles for where the contract tests would apply if I was owning the zip service and just worrying about testing the zip service by itself then I would just own that one set of contract tests and the aim would be that if you have an organization where different teams own different services you would each own your own contract tests and would be in charge of keeping them up to date but everybody owning their own contract tests doesn't really get you the whole way there because the contracts have to be compatible with each other there's no good me as the zip service saying well I don't accept that input and someone else being like but you need to otherwise it will work so you've got to have some communication there and this is where I think the way you structure your organization if you structure it to match up with the microservices approach so you have different teams who end the different services then you can really use contract tests to help with the way your organization communicate so as the team who owns the zip service I would go to each of the different services that I know I call out to and say please give me your contract tests so I get a copy of each of them and line them all up next to each other and from that I can get a picture of what my service contract should be so when I look at all of the individual contract tests my content test should match up in some way and I should be able to see the good connection between them and the reason this is even more powerful is because then if you need to make changes if a new service comes along and says well I want to add this attribute or something along those lines then they can write their service write their contract tests and then pass them over to my team and we can use those contract tests to update our service contract and update our application so this means that not only are you thoroughly testing your applications but you're actually making use of the tests that you've written to make sure that everyone is clear on who communicates with who and what they expect from each other because I think it's fair to say that if you have two people in a room together having a discussion often if they leave they might have slightly different views on what was decided whereas if you have it in a set of tests it's very concrete so I'm now going to move on to covering integration tests so integration testing is a phrase that I think in monolithic application can apply to all sorts of different types of testing and in this particular context with microservices I'm going to be very specific about what I mean by integration testing so by integration testing I mean tests that test the interactions between the different components and their testing for success and that you have error paths in place so they're not really testing for behavior we saw previously that you could have component tests that were some form of integration tests with soething app server but in this case it's just the basic if I make requests is it successful and if I get a timeout am i handling that correctly and in a micro service environment these are the reactions with other services the interaction sorry with other services and with data stores so in our specific application you can see here it's all of the interactions with the different services so although I've drawn one box you would kind of have one for each of the interactions and then your interactions with the service list so that's from the data connected to the service list but there are some things to consider when putting in these integration tests beyond sort of the things you might have had to consider from monolithic applications because they're calling across the wire you can have connection failures that could for cause false errors and could cause your tests to be very unstable so because we've already had the contract test where we're testing for the right attributes and we've got our component tests that check for the behavior and things in some ways you need the integration tests but perhaps you don't need them as close to the developer as you had previously and you could consider moving these tests the build pipeline and what I mean by this is seen quite a few teams where they have the developer write some code and they run unit tests they run component tests and they run their contract test but then as soon as you want to run your integration tests you need to connect up to all the other services so actually at that point you can push your application up to a staging environment where everyone else is staging services live and then you can run your integration tests and that means if the developer wants to check out a quick fix or something that they don't think it's going to affect everyone else they can do the change check that they fix whatever they fixed and then push up to staging and then at that point they run the integration tests and if those fail then maybe they have to go back and think again but it means for those quick changes you're not having to wait to build all the other services for example in order to run your integration tests so having that staging environment and pushing running of the integration tests a little bit later in your board pipeline can be a really useful tool to use so the last strategy that I'm going to cover is end-to-end testing n10 testing is something that having spoken to a few people about how they test their micro service I think quite a few people kind of said oh we're not going to worry too much about that because you know if I have to send up all of my services and run a full end-to-end test it's probably going to fall over in some way it's not going to be that stable and maybe I won't worry too much about it and although I think perhaps you don't want loads and loads of end-to-end tests you do still need end-to-end tests to make sure that your system meets any external requirements so these could be user story or a particular path through your application that you know is quite common and setting up an end-to-end test really is sort of a sanity check but all of your other tests they haven't missed anything there isn't some strange behavior between two different services that causes some other strange thing to happen it's really checking that if you stand everything up it does kind of work as you expected it to and I think the point where you perhaps really can't forget about int end-to-end test and really have to make sure you put them in and make sure they're really effective is if you've got a stateful system if there's a lot of state involved in the sort of behavior and calculations going on in your application then there's a much higher chance that your test doubles or your test service or the way you've done your blackbox testing has missed something in this and actually when you stand everything up together something about the state doesn't follow through quite properly so I think that's the point where you really do need to look carefully at how you're doing your end-to-end testing and the other thing to note with this which I think again is an area that pups can be kind of left to later for a lot of people is the UI testing which is definitely something that shouldn't be left till later and you should be running UI tests and tamasic Qi test because yes you could go and manually look at your URI and see if everything works but the more complicated your UI the more time that's going to take for you to click every button and see if it goes where you expected so you can use tools like selenium or other UI tools to just hit the UI and see what happens and in our particular application the solve workflow that we would have we are and to end tests would be for something like selenium to come to the page select every technology type for example click the download button get the downloaded zip and then perhaps even go as far as building zip I'm running maven install and if everything passes them we're happy our intern test works so I've kind of covered the five different strategies now I'll give you a quick recap so far we've got unit testing which tests the behavior of the individual pieces within your surfaces we have component testing which covers a specific service and we have contract testing which tests the contract that you've defined to call out to other services and these first three you would each team that owns that particular service would own those tests then you have integration testing where you're testing the communication does it is it success or failure between your service and other services external services or data stores and these tests would sort of have to be owned at a more team-wide level if you have your different teams earning of different services and the final one is the end-to-end testing which is a full flow through your entire application to make sure that you have picked up the edge cases and the points where something could have gone wrong with you haven't caught earlier so um I'm going to move on to monolithic to micro service unless anybody has any questions at this point I will open it to questions at the end as well okay we'll move swiftly on so now that I've covered a set of sort of general strategies for testing micro services and how you would do it slightly differently from in the monolithic world I'm now going to talk about what we found moving from a monolithic application through to a microservice application so these are some things that we found and that we feel like you should consider as you're making the move from monolithic applications to micro-service applications the first thing is to add tests for current function and fix flaws later so the reason that I suggest this is previously in our team we've been looking at doing an evolution of a an example which is called plants where WebSphere which is an application built quite a long time ago to do an example of how you would do Java EE applications and as we were doing our moves to micro services there were quite a few things that we thought oh this doesn't really work how perhaps it would be nice for it to work or maybe we should just change this thing and that's quite a dangerous thing to think up as you move through to micro services and the reason for that is even if you have fully tested your application you may find that changing things partway through your evolution can cause unwanted and unexpected problems elsewhere so I think it's important to make sure before you do your evolution that you have a good set of tests but if you do have to write the tests because perhaps you weren't as good at writing the tests as you want to be now and maybe you haven't got the full coverage you were looking for I think the key thing is to add tests for the current function of your application so from the five that we covered perhaps that would really be the end-to-end tests to an external user what does the application do rather than the specifics of how it works internally because ultimately while you to microservices you are going to find that there's individual pieces and how it works is going to change the other thing to consider is that as your monolith changes you will have to change your tests and hopefully from the different strategies I've talked about you might get an idea of what changes you'll have to make and how you might have to rethink how you're doing your testing but just be aware that when you change your monolith you will have to update your test because there will be certain tests that are very specific to that specific where you were doing it before and this is where I'm going to give a little plug for test-driven development because I think if you're writing your new micro-service application then actually writing new tests to replace the old ones might be quite a nice way to do it you can write your tests make sure that it currently fails and then write your new implementation or your new service or something and see that your tests now pass and now I'm just going to call out a few sort of useful things to think about using as you're doing your evolution story in terms of testing so the first one's not necessarily specific to testing but it will enable you to test more easily which is to have quite a small set of classes that call externally to your service so in our diagram I showed you that we have our service connector that calls out all the different services and that's worked really well for us because we can just replace the one class and use that stub class that I showed earlier to test all our different units within our zip service so perhaps keeping that in mind and not going too crazy too quickly and not getting too small too quickly will allow you to have better unit tests and have unit testing that doesn't take up too much your time but gives you the coverage that you really want the other thing to use as I just said is mocking and having test doubles so that's kind of combined with my first point and then the final one is having a test service for component testing and the reason I'm pulling this one out is because it's something that I hadn't really seen before like either the idea of creating a whole new service just as a test piece is perhaps a bit of a strange notion but because your services are smaller than your monolith would have been it does kind of make sense and I think you have to bear in mind the context and for us it made complete sense but perhaps when we go to test our individual technology services having a test service won't make as much sense but it's something to consider so on to my conclusion so I would say this is still very much a developing area as I said there's plenty of talks at this conference about micro services but I I'm pretty sure I'm the only person talking about testing micro services so I definitely think it's an area that you know we need to look into more and when you're writing your micro services test them as you go along and don't leave it as something that you think about later because in some ways by writing a really good set of tests you can be even more sure that your application is doing exactly what you expected it to do and that when it fails or when you do something that breaks someone else you'll know about it and particularly when we're moving to organisations that are structured around the different services you can really use the way you test to enable you to have better communication between the different parts of your organisation and the different owners of the different services as I said in my previous slide I think having a dummy service or a test service is a really useful tool but you should really adapt your tests to suit the development and deployment process so at each stage of the different testing strategies I've talked about a couple of different options and it's definitely true that you could just pick one of the two options or you could do both or you it's kind of up to you and it really depends on what your application is doing oh so that's kind of the end of my talk I do have some slides about my thoughts on Gradle or may even if everyone any wants to come and talk to me afterwards and in terms of sort of extra reading there's a really good slide set from Martin Fowler which is the link at the top of there which I would definitely recommend you go away and read and if you want to learn about more macro services in general then if you go to West fnet which is the WebSphere Liberty sort of developer site where we have a lot of documentation and you can download liberty and stuff and if you go to Doc's micro services you'll find some more articles by me about twelve fat traps and some other things around micro services and some other documents and articles from my other colleagues about logging and other things from our micro services and if you want to check out the Liberty starter feel free it's at IBM dot biz slash Liberty starter so thank you very much any questions what tools do you use for contract tests or how how to do this so for our contract tests we're using j-unit and we're actually starting up a Liberty server in order to run our contract tests and accessing them via rest the other sort of useful tool but we're hoping to start using we're not currently is using our quillion so if you find that there's certain pieces in your application that if you don't start them up in quite the right way there and serve it it doesn't run them and if you have CDI and things like that if you start if you use our Quilly and then you can have all the pieces start up correctly but for us we're just setting up rest requests into our api's and starting up a Liberty server because the it's worth noting the WebSphere Liberty is very quick to startup and shutdown so we found that actually like I said earlier for our component test we're using a test service because we found actually starting a Liberty didn't cost us that much so when doing the contract testing you pointed out that you also tested the outbound contract from the sip service how do you do that because then then it's not about calling another service it's about being the testing the Cawley yes so it's about checking that your rest endpoints are accepting the calls that you expect so if you make some calls in that have attributes that shouldn't be allowed you need to check that your rescue line is kind of handling that so you can kind of still test it in that way and but I think the key thing is that you you will find you'll have more tests of their outgoing and incoming but then when you combine that with the other people's contract tests then that's kind of the comparison of those two contests is kind of the way that you can make sure that you really are testing effectively because you as long as your incoming calls accept the ones that you know are coming in that make sense then it kind of covers so I think they are in answer to your question it is more difficult to test that nudge it you can test it as effectively but the key thing is to make sure you combine your contract test with someone else's contract test and you can't write your contract tests completely separately from the other team there has to be some communication because otherwise it just won't work have you been involved in a testing the deployment of a micro services so at this point now I haven't really looked into how you test your deployment so for our application at the moment after we deploy it we run some tests and we've set up some monitoring but it's certainly an area that I want to look into further because it's I haven't found that much information about so good ways to do it so at the moment I say we deploy our application and then we do a quick sort of is it responding test but nothing more detailed than that and certainly an area that I want to look into more thank you if you're going from monolithic architecture to to micro service architecture and you decide to start off with building lots of tests seems to me that the unit tests and the and scientists should be more or less intact but the middle tests need to change or is it even meaningful to implement such tests on the monolith and so yeah so you're kind of asking if my monolithic application is there much point in introducing tests that are tests that aren't really effort to be testing the Model S just because we know later we'll need them so I would say that there's a very valid point and I think the tests that you would look to add if you don't have any tests on your monolithic application is the sort of end-to-end testing and perhaps you wouldn't look at the specific unit tests but if you don't have any tests on your monolith then you certainly should because it will help you a lot in knowing when you have got something right while you're doing your evolution in terms of the new tests that you write on top of the ones you already have I think focusing on writing the tests as you write your services is kind of the key points so you don't need to I'm not saying you should write a test that you then don't have any implementation for yet the idea would be you would write say I'm going to create a service and as you create your service write your tests for your service and then at some point you will need to connect your service into your monolithic application so the approach we kind of took was working out what service we were going to create creating it and then changing the monolith to then call out to that service so the unit test and the component tests and things would be testing the micro service or the individual service so I think the unit test and component test you would have on the monolith you would want to leave until later until you have removed all of the sort of pieces that have now been extracted out and then you can then implement meaningful unit and component tests I think that's kind of the workflow that you'd want to follow I are consumer driven testing equivalent to the term contract trusting that you are used consume it rabbit test anger and tools like pack do so I think I guess the key difference would be the um by consumer driven testing do you mean from the user or from no it's a the tool pack to basically records the outbound requests that you're going to do and then you give them to the service provider and then they record your requests the written responses and you can done around the circle yes so I think that would be the equivalent of testing of the contract testing the key thing is to make sure that you're the those specific tests aren't checking for behavior is just the call but yeah I think the consumer testing would be the equivalence of contract testing any more questions oh I think let's find out thank you very much thank you very much everyone

Channel: Jfokus

Views: 20,170

Keywords:

Id: uUR8m8AdJvM

Length: 49min 10sec (2950 seconds)

Published: Tue Feb 23 2016