As a software consultant, I have had the pleasure to work with many different companies and software development teams. I have seen what works and what doesn’t. The first thing I notice though are the tools they use, or the lack thereof. The saying, “you don’t know what you don’t know” is true. I know for myself that if I hadn’t seen a better way, I wouldn’t have seen the hole I was in. I keep learning new ways to do things from people like you. I hope some of the things I’ve learned can help you as well.

Dedicated Work Environments

Working as a team means first working better as an individual. Having your own environment to perform code development can improve your productivity. When you develop and test in a common test environment you have to coordinate times to deploy your code, restart the server and when to upgrade dependencies. You also hurt the productivity of others if you accidentally break the environment they are working in.  

Having your own environment gives you the freedom to try new things and test features in ways you wouldn’t or shouldn’t attempt in a shared environment. Once you prove out your new feature, then it’s time to merge your changes in with others and deploy it to common development and test environment.

Using a Virtual Machine (like Docker)

Using a VM like Docker makes it even easier to not only share your code but entire enterprise-level environments. With wifi bandwidths and internet connections averaging 5MB/s upload and 50 MB/s download it only takes an hour or two to download a new VM.  Uploading a new VM usually takes longer but it can be uploaded a piece at a time or the whole thing overnight. People on your team can download these VMs and take advantage of what you have built without a lot of downtime. 

The primary reason development teams don’t take advantage of these VMs is due to the complexity and the time it takes to simulate an environment. With Docker, there are many tools available to build these environments from the ground up. You’re probably not the first one needing the environment you’re looking for and can take advantage of many open-source build scripts available from the community. 

Docker also lets you version your image the same way you version your code. Since run-time environments change over time, you can push environmental changes to a hub, so others can work from the latest environment configurations too. Also with Docker you only need to push or pull the latest changes, not the entire image. So pushing or pulling changes becomes faster over time.

API Mocking Tools  

API mocking tools can provide you with the ability to test your code with a higher degree of flexibility then you would get with real live systems. That is because the actual service may also be a development version or you may not get sufficient variability or control to test your changes. With a mock service, you can add new scenarios that pertain to the test cases you need. 

Developing code in a local environment can also be a problem if the system needs to integrate with external systems like; financial systems, a document repository, email services, custom services, external databases, or CRM systems.  Without them, your local environment may not work well enough to use effectively. With these API mocking tools, this is not an obstacle. By creating mock services that simulate these integration points, you can test everything you need quickly, locally and independently before impacting others on your team.

There are several free and proprietary tools available that can be used to mock up external systems. If your company already has a license for proprietary API management or mocking tools, you should consider it before using free open-source versions.  Although free tools may be quicker and easier to use on your own, long-term implications for your choice of technology can come back to haunt you.

Tool Name	Company	Free Version	Description	Link
Swagger	SmartBear	Yes	Swagger codegen can be used to model REST service APIs. Payloads are typically JSON.
SOAP-UI	SmartBear	Yes	SOAP-UI can quickly model and test WSDL-based interfaces,  and REST services defined by a WADL.
Postman	Postman	Yes	Can mock and test both WSDL and REST services.
Apiary	Oracle	No	Models and implements REST services APIs and provides API documentation. Part of Oracle Cloud Services
Apigee	Google	No	Can host cloud and on-prem models and services. Part of the Google Cloud Service.
Mulesoft	Salesforce	No	Models and implements REST services with on-prem and in cloud offerings.

Automated Build Scripts

I also recommend that you create good build and deploy scripts. Your team should be able to deploy changes to any platform, remote or local, using automated scripts that can reduce the chance of errors when rolling out changes. This should not only include building and deploying your code, you should also consider automating deployment of your mock services and environmental changes as well. Here is a list of open-source tools available to you.

Let’s Do It

For some, this may be a review. If you’re already doing these things, check out the links below for more ideas. If you’re not doing them try to start small and continuously work to add them in over time. Your manager, coworkers or business owner may not appreciate what you’re doing at first, but show them a little of what they don’t know. Start with some simple mock services, or build scripts. Develop them as part of the other tasks you are doing. When you get enough to show off, share it with others on your team. As I said before, working better as a team starts with working better on your own. The freedom you get to test something quickly and report back will make you and your team work better together.

Where to go from here

Try these links:

Getting Testy SOA 11g Part 1 and Part 2

Bridging the gap between business and development team business analyst 

Testing Mulesoft apikit Munit

Setting up CI/CD Pipeline in Mulesoft