\r\npublic class BookingFacade : IBookingFacade\r\n{\r\n public Response Price(Models.GetPriceRequest request)\r\n {\r\n \/\/ in real life scenario Pricer should be injected\r\n var pricerService = new Pricer();\r\n var response = new Response();\r\n try\r\n {\r\n var tradingDates = pricerService.GetTradingDates();\r\n var price = pricerService.GetPrice(new GetPriceRequest\r\n {\r\n IsAdvised = request.IsAdvised\r\n });\r\n\r\n \/\/ rest of the code omitted for brevity\r\n response.Result = new Price\r\n {\r\n TradingDates = new TradingDates\r\n {\r\n MaturityDate = tradingDates.MaturityDate,\r\n SettlementDate = tradingDates.SettlementDate\r\n }\r\n };\r\n \/\/ rest of the code omitted for brevity\r\n }\r\n catch (Exception ex)\r\n {\r\n \/\/ rest of the code omitted for brevity\r\n }\r\n return response;\r\n }\r\n}\r\n<\/pre>\nBookingFacade<\/i> uses Pricer<\/i> service which basically is just a wrapper for external\/downstream service we have to use in order to retrieve some data (and we do not have an ownership of that service).<\/p>\n\r\npublic class Pricer : IPricer\r\n{\r\n public TradingDates GetTradingDates()\r\n {\r\n using (var webClient = new WebClient())\r\n {\r\n var result = webClient.DownloadString(ConfigurationManager.AppSettings[\"MockingDownstreamServices.Externals.Pricer.GetTradingDates\"]);\r\n return JsonConvert.DeserializeObject(result);\r\n }\r\n\r\n public Price GetPrice(GetPriceRequest request)\r\n {\r\n using (var webClient = new WebClient())\r\n {\r\n var result = webClient.UploadString(ConfigurationManager.AppSettings[\"MockingDownstreamServices.Externals.Pricer.GetPrice\"], JsonConvert.SerializeObject(request));\r\n return JsonConvert.DeserializeObject(result);\r\n }\r\n }\r\n}\r\n<\/pre>\nVery simple end-to-end test for BookingFacade<\/i> can look like that<\/p>\n\r\n[TestFixture]\r\npublic class BookingFacadeTests\r\n{\r\n [Test]\r\n public void CanSuccessfullyPriceTest()\r\n {\r\n var response = this.Price(new GetPriceRequest());\r\n Assert.IsNotNull(response);\r\n Assert.IsNotNull(response.Result);\r\n Assert.IsFalse(string.IsNullOrWhiteSpace(response.Result.Id));\r\n CollectionAssert.IsEmpty(response.Messages.Where(val => val.StatusCode == StatusCodes.Error));\r\n }\r\n}\r\n<\/pre>\nAs I mentioned before, everything is fine as long as all of the downstream systems are working. The moment one of them is down, our tests start failing.
\n![\"FailingTests\"](\"\/\/tpodolak.com\/blog\/wp-content\/uploads\/2016\/02\/mocking-downstream-services-with-mountebank-part-one\/FailingTests.png\")
<\/a><\/p>\n3. Implementation<\/h3>\n
General idea to fix this problem is to use fake downstream systems during end-to-end testing. In order to do that we use combination of custom compilation profile, app.config<\/i> transformations and mountebank<\/a> test doubles. <\/p>\n3.1 Setting up transformations<\/h4>\n
First of all we will create a custom compilation profile called test.integration<\/i> which will be used for running tests with mocked downstream systems (we want to preserve the normal use of downstreams for Debug<\/i> and Release<\/i> mode). In order to do that, go to ConfigurationManager<\/i>
\n![\"ConfigurationManager\"](\"\/\/tpodolak.com\/blog\/wp-content\/uploads\/2016\/02\/mocking-downstream-services-with-mountebank-part-one\/ConfigurationManager.png\")
<\/a>
\nand follow the steps presented in the pictures below
\n![\"ConfigurationManager2\"](\"\/\/tpodolak.com\/blog\/wp-content\/uploads\/2016\/02\/mocking-downstream-services-with-mountebank-part-one\/ConfigurationManager2.png\")
<\/a>
\n![\"ConfigurationManager3\"](\"\/\/tpodolak.com\/blog\/wp-content\/uploads\/2016\/02\/mocking-downstream-services-with-mountebank-part-one\/ConfigurationManager3.png\")
<\/a><\/p>\nNow it is time to prepare our app.config<\/i> for transformations. We can do it manually but for sake of simplicity I will use SlowCheetah<\/i> extension. Go to Tools->Extensions and Updates<\/i> and install
\nSlowCheetah – XML Transforms<\/a>. Once extension is installed you will see a Add Transform<\/i> item in a config files’ context menu.
\n![\"AddTransform\"](\"\/\/tpodolak.com\/blog\/wp-content\/uploads\/2016\/02\/mocking-downstream-services-with-mountebank-part-one\/AddTransform.png\")
<\/a>
\nClicking Add Transform<\/i> will create three files: App.Debug.config<\/i>, App.Release.config<\/i> and App.Test.Integration.config<\/i>. What is more, some additional changes will be added to your csproj<\/i> file, which will be responsible for applying transformations during a build process. These three additional files hold information about config transformations. The default App.config<\/i> file looks like that<\/p>\n\r\n\r\n\r\n \r\n \r\n <\/appSettings>\r\n<\/configuration>\r\n<\/pre>\nNothing special in here but note the empty file<\/i> attribute in appSettings<\/i> node. The value of this attribute will be replaced with proper filename during transformation process. In order to do that let’s implement tramsforms for every of three config files we use<\/p>\n
App.Debug.config<\/i><\/b><\/p>\n\r\n\r\n\r\n\r\n \r\n <\/appSettings>\r\n<\/configuration>\r\n<\/pre>\nApp.Release.config<\/i><\/b><\/p>\n\r\n\r\n\r\n\r\n \r\n <\/appSettings>\r\n<\/configuration>\r\n<\/pre>\nApp.Test.Integration.config<\/i><\/b><\/p>\n\r\n\r\n\r\n\r\n \r\n <\/appSettings>\r\n<\/configuration>\r\n<\/pre>\nAs you can see I apply SetAttributes<\/i> transform for appSettings<\/i> node, which means that the transformation will replace appSettings<\/i> node attributes from app.config<\/i> file with appSettings<\/i> node attributes from transform file. You can preview results of transformation by clicking Preview Transform<\/i> context menu option available for every of our transform files
\n![\"Preview\"](\"\/\/tpodolak.com\/blog\/wp-content\/uploads\/2016\/02\/mocking-downstream-services-with-mountebank-part-one\/Preview.png\")
<\/a>
\nAs you’ve probably already figured it out app.settings.debug<\/i> and app.settings.release<\/i> fileses contain real downstream endpoints and app.settings.tests.integration<\/i> contains addresses of fake endpoints. Of course you have to create those files and copy them to output directory during the build (for instance by using Copy to Output directory<\/i> option).<\/p>\n3.2. Creating fake downstreams with mountebank<\/h4>\n
Setting up fake downstream systems completely from scratch would be a very painful and time consuming process. Fortunately there are tools which can make this task easier. The tool I use is called mountebank<\/a> – you can easily install it via npm<\/i><\/p>\n\r\nnpm install -g mountebank\r\n<\/pre>\nHaving mountebank<\/i> on board it is time to configure it, so that it acts as fake Pricer<\/i> service. It can be done in couple of ways but I will go with file based configuration. You can run the tool using following command<\/p>\n\r\nmb --configfile impostors.ejs --allowInjection\r\n<\/pre>\n![\"ImpostorsListening\"](\"\/\/tpodolak.com\/blog\/wp-content\/uploads\/2016\/02\/mocking-downstream-services-with-mountebank\/ImpostorsListening.png\")
<\/a>
\nWhere impostors.ejs<\/i> is a configuration file with following structure<\/p>\n\r\n{\r\n \"imposters\": [\r\n <% include pricer.json %>\r\n ]\r\n}\r\n<\/pre>\n<% include pricer.json %><\/i> is EJS<\/a><\/i> syntax which (in this case) allows you to split configuration into multiple files. As you’ve probably already figured it out, Pricer.json<\/i> contains the actual mock configuration for Pricer<\/i> service. The initial mock object consists of couple of properties which setup the name, port and protocol for given mock. <\/p>\n\r\n{\r\n \"port\": 4545,\r\n \"protocol\": \"http\",\r\n \"name\": \"pricer stub\",\r\n \"stubs\": []\r\n}\r\n<\/pre>\nNote that we do not specify the address of mock but just a port. Mountebank<\/i> by default runs on http:\/\/localhost:2525<\/i> and mocks listen on http:\/\/localhost:{port}<\/i>. The actual magic happens in stubs<\/i> property.
\nHere is an example of stub\/mock for GetTradingDates<\/i> method.<\/p>\n\r\n{\r\n \"responses\": [\r\n {\r\n \"is\": {\r\n \"body\": {\r\n \"MaturityDate\": \"2016-02-17\",\r\n \"SettlementDate\": \"2012-02-23\"\r\n }\r\n }\r\n }\r\n ],\r\n \"predicates\": [\r\n {\r\n \"equals\": {\r\n \"path\": \"\/GetTradingDates\",\r\n \"method\": \"GET\"\r\n },\r\n }\r\n ]\r\n}\r\n<\/pre>\nAs you can see stub object consists of two properties<\/p>\n
\n- responses<\/li>\n
- predicates <\/li>\n<\/ul>\n
responses<\/i><\/b> property is an array of objects mountebank<\/i> will be using to create a response. If you insert multiple items into array, they will be utilized using round robin algorithm. Note that you don’t have to create a full response (with all the headers etc.) just use “is” property which will fill the default values for you. More about that topic can be found here <\/a> but in most of the cases setting value for “body” property will be enough for you.<\/p>\npredicates<\/i><\/b> property is an array of predicates which will be used during matching process. Predicate object can be quite complex, it supports lots of different matching techniques. In this case, for simple GET<\/i> method I just use equals<\/i> operator to match HTTP<\/i> verb and HTTP<\/i> method.
\nThe same technique can be used for stubbing POST<\/i> methods. However, in this case, you can also perform matching against the body of the request. The one thing you have to remember is that body<\/i> property is not an object but string. So in my case, if I want to make a stub for GetPrice<\/i> which takes as params following request object <\/p>\n\r\npublic class GetPriceRequest\r\n{\r\n public bool IsAdvised { get; set; }\r\n}\r\n<\/pre>\nI can write for instance this stub<\/p>\n
\r\n{\r\n \"responses\": [\r\n {\r\n \"is\": {\r\n \"body\": {\r\n \"Id\": \"1\",\r\n \"Strike\": \"1\"\r\n }\r\n }\r\n }\r\n ],\r\n \"predicates\": [\r\n {\r\n \"equals\": {\r\n \"path\": \"\/GetPrice\",\r\n \"method\": \"POST\",\r\n \"body\": \"{\\\"IsAdvised\\\":false}\"\r\n }\r\n }\r\n ]\r\n}\r\n<\/pre>\nOf course for more complex request it is pointless to write every possible combination of params. Fortunately you can create fallback\/default stub which will match everything<\/p>\n
\r\n{\r\n \"responses\": [\r\n {\r\n \"is\": {\r\n \"body\": {\r\n \"Id\": \"default\",\r\n \"Strike\": \"1\"\r\n }\r\n }\r\n }\r\n ],\r\n \"predicates\": [\r\n {\r\n \"equals\": {\r\n \"path\": \"\/GetPrice\",\r\n \"method\": \"POST\"\r\n }\r\n }\r\n ]\r\n}\r\n<\/pre>\nIf you put this at the very end of stubs array it will not interfere with other stubs.
\nThis is of course just a tip of the iceberg when it comes to predicate matching. Explanation of all possible matching options can be found here<\/a><\/p>\n4. Results<\/h3>\n
From now on running tests against test.integration<\/i> compilation profile and having mountebank<\/i> working in the background, our tests will be green.
\n![\"SuccessfulTests\"](\"\/\/tpodolak.com\/blog\/wp-content\/uploads\/2016\/02\/mocking-downstream-services-with-mountebank\/SuccessfulTests.png\")
<\/a>
\nSource code for this post can be found here<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"1. Introduction I’m a part of a team which creates large enterprise platform for the banking sector. Due to the fact that we operate in the financial area, our application consumes a high amount of downstream services. One of the major problems we are facing at the moment is the inaccessibility of those services on […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[292,291],"tags":[294,293],"class_list":["post-614","post","type-post","status-publish","format-standard","hentry","category-mountebank","category-testing","tag-mountebank","tag-testing"],"_links":{"self":[{"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/posts\/614","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/comments?post=614"}],"version-history":[{"count":62,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/posts\/614\/revisions"}],"predecessor-version":[{"id":1074,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/posts\/614\/revisions\/1074"}],"wp:attachment":[{"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/media?parent=614"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/categories?post=614"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/tags?post=614"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}