![\"1\"](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2018\/07\/1.jpg\")
<\/a><\/p>\nOur applications have evolved. We started with monolithic, all-in-one systems that are fairly easy to write and fairly simple to test. But as we add more code (even in a time-boxed agile process), our testing effort is always increasing.<\/p>\n
When we deploy, we always deploy everything \u2013 even if we didn\u2019t change it.<\/p>\n We found ourselves in a state where it\u2019s pretty easy to write code and testing is a solved problem, but the time to test is always increasing. Therefore, getting code to production is now quite an effort in unpredictable time.<\/p>\n (There are also development and architectural problems with a monolithic approach to applications that we will not get into at this time.)<\/p>\n Our answer was to make our applications smaller.<\/p>\n In moving to SOA, we broke apart our applications into their logical subsystems and treated each subsystem as a separate application, so each application now has much smaller scope and vastly less code to test. We still have the problem of an ever increasing code base, but it\u2019s more manageable.<\/p>\n Each application connects to any dependant applications over some type of common communications structure; HTTP is very popular for this purpose. So when each application requires some functionality from another application, it simply makes a request over that common communication structure\u2026which led us to the dreaded, \u201cSpaghetti Diagram.\u201d<\/p>\n Our applications were now simpler, but their interactions were vastly more complex, making testing them very difficult. We traded a tightly coupled monolith for a tightly coupled enterprise application and we didn\u2019t really have the skills to test at the network layer in our testing professionals. Because of the tight-coupling and unknown dependencies, it was still tough to test and get into production.<\/p>\n An answer to tightly-coupled SOA applications is to use a \u201cShared Messaging\u201d infrastructure to orchestrate the interaction between components. Applications in the system simply generate messages and await responses, while the enterprise infrastructure manages routing messages and responses.<\/p>\n The content of the payloads that are passed between the two are governed by the enterprise application team and agreed on as a standard of communications. These agreements are often called contracts.<\/p>\n Other benefits include;<\/p>\n Two common examples are below.<\/p>\n Systems that use an ESB utilize a software package to route messages and provide process orchestration between components.<\/p>\n ESBs can be quite effective but they are expensive, hard to maintain, require specialized skills and are hard to test.<\/p>\n An alternative approach to the ESB is EDA. In EDA, applications interact by producing and consuming messages that are distributed by an event channel (usually queues). Conceptually, individual applications react to events that occur in some other application by processing the resultant message. In EDA an event typically represents a \u201csignificant change in state 2<\/a><\/sup>.\u201d<\/p>\n In these messaging-based infrastructures, we gain the smaller applications that we tried to get in SOA that are easier to design and test with loose-coupling between sub-systems that make it easier to test applications in isolation.<\/p>\n Because of the messaging infrastructure, our application teams are free to build large applications or microservices, utilizing the technologies that are best suited for the job. Our enterprises can be a combination so long as all applications obey the contracts for messaging.<\/p>\n Many modern applications that utilize a service based architectural design pattern will typically utilize an ESB or EDA.<\/p>\n Our approach to testing internal application functionality doesn\u2019t change, but what does change is how we do integration testing. The contracts give us the ability to test in isolation because we know the format of what we produce and consume. We use the contract to test system integration at its \u201cEdges.\u201d But \u2013 these are not standard testing approaches. It\u2019s important for the tester to understand how the applications are constructed and how they interact with each other. The tester might need an additional set of skills that are more technical in nature. Once you have developed these skills, a whole new world of testing capability becomes available to you.<\/p>\n It becomes important for the tester to know in detail certain terminology around these design patterns.<\/p>\n To test these applications, we need to find their edges and test at those boundaries, by passing messages in and examining the messages that are generated. There are several tools available that aid in this testing. These tools generally fall into two categories: manual and automated.<\/p>\n Manual<\/strong><\/p>\n Manual testing tools allow the tester to construct messages, send then to the component and see the output. Two common tools are Fiddler and Postman.<\/p>\n Automated<\/strong><\/p>\n Automated testing tools allow tests to be assembled into a suite and run together without manual intervention. A common approach is to use a Domain Specific Language like Gherkin and its most popular implementation of Cucumber<\/u>.<\/p>\n Determining which approach will work for your team and backlog should be a collaborative effort. Spend some time researching the design patterns, terminology and tooling and you should be better equipped to provide testing value to your team in a microservices oriented world.<\/p>\n Shawn Wallace explores the evolution of software design with the goal of understanding of high-level application architecture.<\/p>\n","protected":false},"author":63,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_oasis_is_in_workflow":0,"_oasis_original":0,"_oasis_task_priority":"","_relevanssi_hide_post":"","_relevanssi_hide_content":"","_relevanssi_pin_for_all":"","_relevanssi_pin_keywords":"","_relevanssi_unpin_keywords":"","_relevanssi_related_keywords":"","_relevanssi_related_include_ids":"","_relevanssi_related_exclude_ids":"","_relevanssi_related_no_append":"","_relevanssi_related_not_related":"","_relevanssi_related_posts":"","_relevanssi_noindex_reason":"","footnotes":""},"categories":[1],"tags":[],"coauthors":[15012],"acf":[],"publishpress_future_action":{"enabled":false,"date":"2024-07-22 00:50:41","action":"change-status","newStatus":"draft","terms":[],"taxonomy":"category"},"_links":{"self":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/posts\/13086"}],"collection":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/users\/63"}],"replies":[{"embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/comments?post=13086"}],"version-history":[{"count":0,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/posts\/13086\/revisions"}],"wp:attachment":[{"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/media?parent=13086"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/categories?post=13086"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/tags?post=13086"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/centricconsulting.com\/wp-json\/wp\/v2\/coauthors?post=13086"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}<\/a><\/p>\nService-oriented Applications (SOA)<\/h2>\n
<\/a><\/p>\n<\/a><\/p>\nShared Messaging Infrastructure<\/h2>\n
\n
Enterprise Service Bus (ESB)<\/h2>\n
<\/a><\/p>\nEvent-Driven Architecture (EDA)<\/h2>\n
<\/a><\/p>\nTesting<\/h2>\n
Terminology<\/h2>\n
\n
Tooling<\/h2>\n
\n
Resources<\/h4>\n
\n