Good design lends itself to being Easier To Change [ETC]. However, this principle of ETC tends to get ignored when it comes to API documentation and service validation. Here the tenants of Do Not Repeat Yourself [DRY] are often neglected leaving services with multiple files potentially spanning hundreds if not thousands of lines of code with copious amounts of duplication.

Development in services with monolithic validation engines and swagger documents then become a form of tech-debt. …

Enterprise microservices tend to be a combination of technologies. The objective of this post is to go over multiple approaches to different scenarios commonly found in enterprise JS services.

The Scenarios:

  1. Testing a service-call with an XML request to an enterprise SOAP service
  2. Testing a standard POST call to an enterprise service
  3. Testing a database connection and related queries
  4. Testing an LDAP connection and related searches
  5. Testing an express route containing one or more of the above

Before we get into the article, you can find most code samples inside this Github repository I threw together for this.

The Objective


Matthew Zygowicz

Senior Full-Stack developer building awesome things at Northwestern Mutual

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store