Story

No matter which technology, platform, or tool you engineer your microservices or APIs on, many engineers are following the Model-View-Controller (MVC) like design pattern of using API layers in their solution architecture. Some classify this approach as: Experience, Process, System layers of microservices and APIs. Others have different vocabularies for these same layers, but semantically, they are often the same purpose. Categorize microservices and APIs into layers and hierarchies. Common Object Oriented programming techniques. In Microservice and API Testing, its important to test all layers of your solution. In a different article, we will explore the order of developing each layer.

This article illustrates the order for microservice or API Testing, whether it be Unit Testing, Integration Testing, or Performance Testing.

The Testing concept is pretty simple: Test your layers Bottom-Up. Test a bottom layer Microservice and API first. Once passed defect free, test the next layer up if such a layer exists on the same Microservice or API. (Note, its important to Test Case each Microservice and API independently to remain “Agile compliant”, so you don’t necessarily have to Test Case every Microservice or API in the layer). This approach allows you to test lower levels of solution granularity, and move up the chain as test cases pass, to test more coarse grained levels secondarily. Why? Because its a process of elimination to minimize possible defect impacts and scenarios, and allows the Test Team to eliminate potential defect impacts. For example, if you find a defect in a higher layer of your microservice or API, there’s a good chance the root cause is not from a lower level microservice and API, because you already passed the test case.

What’s the last architecture layer to test? Answer: The Application or System User Interface. Only after the core Microservices or APIs pass, then you test your App. (Again, keeping agile concepts in mind, you can test an App page or a component in your App, so your not waterfalling into all APIs being built in order to test the App or UI). Testing your App or UI before testing your middle tier will just lead you on a wild goose chase trying to determine the defects.

The graphic below illustrates the Bottom Up Microservice and API Testing approach:

The reason why I say it’s “disruptive”, is that many Quality Assurance and Testing teams have traditionally tested Top Down. So, this approach is different than how they have done testing in the past. With change comes opportunity !

Story

Microservice Frameworks consist of reusable standards, patterns, examples, constraints, and instructions that help accelerate project delivery and allow for consistent repeatability. Frameworks are assets so that can be leveraged by multiple teams or at an enterprise level. While the overall objective of any software initiative is to create functional business solutions, the frameworks are the enablers. They are non-business-oriented assets

In the diagram below, the Frameworks are the “Horizontal Assets” because they are re-usable across Functional Use Cases (Functional Use Cases also referred to as “Vertical Assets”).

The purpose of frameworks includes the following:

Enables acceleration of Functional Use Cases. Functional Use Cases need to be developed and deployed to release product and business solutions. The framework should provide a mechanism to enable efficient and rapid engineering, testing, deployment, and operations of such product. Without repeatable frameworks, each functional Use Case becomes a 1-off approach without consistency, often leading to spaghetti.

Standardizes approaches across projects for easier governance, change management. Frameworks allow your organization to manage multiple Microservice and Integration projects, solutions, and associated IT assets across teams, business units, and shared applications in a consistent approach. For example, the standard allows for making changes to an Integration Asset and minimize the impacts of that change. Meaning, it should not cause a long SDLC to make the change, because the standards allowed for changes to be incorporated.

Enterprise Approach. Frameworks allow for multiple teams, business units, business processes, shared applications, and project to focus independently on their business solutions and not worry about creating architecture or repeatable assets. The frameworks bring these independent solutions together through enterprise management and without conflicts, without misunderstandings, and enables a solution path for local and enterprise level conventions.

For example, the Citizen Microservice developer can work on the Functional Use Cases (Verticals), while the Microservice C4E or COE works on the repeatable frameworks (Horizontals).

Operations. Frameworks enable efficient and streamlined operations and sustainment of the Microservice Solutions. For example, for framework such as: “Naming Conventions”, an Integration Administrator shall be able to view API’s across projects in a single webpage screen and easily understand which API’s are associated with which projects and business processes.

Allows for collaboration amongst organizations and people working on Microservice Solutions. Most companies have multiple shared applications, business units, and parallel projects. People working on these efforts need to be speaking the same language and collaborate within or across project teams. Creating the standards through frameworks allows for the people to collaborate more quickly, not spend time discussing syntax and naming standards since its already established and allow for meaningful handover or collaboration across people within or across project teams.

Simplicity and Pit of Success. Frameworks ensure simplicity and allow users to fall into the “Pit of Success” easily and without major effort (Reference: https://english.stackexchange.com/questions/77535/what-does-falling-into-the-pit-of-success-mean). Make the frameworks easy to use, easy to adopt, and easy to change over time.

Extensibility. The framework can be expanded to include additional IT assets and Microservices platforms and technologies.

Automation. By creating a standard practice and discipline, automation tools can be applied to review quality, automate build/deploy/release, search/replace, and more. With the adoption of DevOps approaches, the frameworks shall align for more streamlined approaches.

Consistency. By making solutions consistent across projects, business processes, and operating companies, it becomes repeatable and lowers the time effort associated with building and operating solutions; provides clarity where there could be ambiguity;

Re-Usable: The frameworks are re-usable within projects, across projects, across business process, and across operating companies.

Discoverable: The frameworks allow for IT assets to be located with ease. For example, the Naming Conventions improve the overall consumer experience in finding API’s in the API Marketplace.

Runtime Performance enabled: The framework provides for efficient runtime performance, tuning, and a foundation for near real time Integration Assets.