Ease Automated Testing of Reusable Components

November 10, 2013

In an earlier post, I listed reasons why automated tests are foundational for reuse. In this post, want to provide some approaches that will ease automated testing of your components.

  • Mock API interactions when using external dependencies. Mocking will reduce runtime dependencies and make your unit tests faster and more robust. Use JUnit with Mockito – mockito has excellent support for a variety of mocking use cases.
  • If an external dependency is required from multiple classes, you can define an Adapter that will wrap the external API via an interface. The interface can then be mocked or stubbed and will provide an abstraction layer for your classes. Word of caution: abstractions are leaky and resist the need to wrap every single API provided by the external dependency.
  • Use in-memory databases and provide a consistent API for your tests. A common class could initialize and clean up the in-memory db and can be leveraged from tests. Alternatively, it can be provided as an abstract class that your tests can extend. Take the opportunity to standardize location, naming, and directory structure of test resources – if you are using maven for instance, the db related data files can be placed under src/test/resources/db/<db-name>. Finally, this is very useful in ensuring that the database-bound code is indeed testable – forcing the in-memory db test will make technical debt apparent.
  • Use db-deploy or some automated database deployment tooling to define and populate databases from tests – these can enable developers to define and execute tests without sharing / corrupting each other’s data. It will also make your database deployment repeatable and well tested eliminating a key deployment risk.
  • Provide a common API for routinely used tasks for developers – e.g. APIs that can create test data in in-house / proprietary formats, parse, and populate appropriate data structures will be useful.
  • Use JUnit Rule extensions for having a common API for developers – provide a custom rule that will manage the lifecycle of a legacy component or a API that is difficult to use – these are all opportunities to both facilitate testing and add value via reuse.

Software Reuse Quick Tip #28

May 2, 2011

Distribute Configuration For Various Testing Needs

If a reusable component requires runtime configuration (properties, XML files etc.) alongside the binaries, make it easier for the asset’s consumer to integrate these artifacts in their tests. For instance, using maven assembly the configuration files can be packaged as a jar file and added in the test scope. This will make the configuration available in the classpath when executing unit tests in the module. The configuration can be packaged per environment and using the dependency classifier the appropriate artifact can be used. This approach works for integration and performance testing as well – for instance, performance tests might use a different set of values for the configuration artifacts since they execute in a dedicated environment.

Checklist for Testing Service Capabilities in your SOA

April 17, 2010

Download Checklist

Here is a checklist for ensuring that your service capabilities are unit tested effectively.   These questions can come in handy when validating test coverage or when doing code reviews with fellow team members. I have used this checklist extensively in all my SOA development efforts and has helped with improving the quality of the services. The check list covers:

  • functional testing
  • error handling
  • data validation/formatting
  • performance testing
  • data binding/transport interfaces

Feel free to add/customize this checklist based on your team’s unique needs. I hope you find this resource useful!

Execute A Systematic Software Reuse Pilot

April 16, 2010
Before you go organization-wide with the systematic reuse strategy it is surely worthwhile to get a pilot project (or multiple pilots even) going. The objective of the pilot is to test how well your reuse strategy can be applied to a real-world application. In a nutshell, here is what a pilot could be:
  • Get engaged with 1 or 2 projects early in their lifecycle and identify reusable business and technical components based on their business needs. The key is identification – not necessarily implementation/realization. With the agile software reuse approach, we can refactor existing code to reuse or plan known assets as part of iterations on a as-needed basis.
  • Identify folks from the pilot projects who are receptive to reuse and work with them closely. You want reuse evangelists, like-minded developers and technical leads who share the possibilities of reuse. It helps if they are also aware of the pitfalls and challenges with reuse.
  • Collaborate with the project team to design new reusable components and integrate existing ones. Identify components that are : unique to an application, unique to a product line, unique to a domain, and relevant across multiple domains
  • Prioritize assets from above list based on project constraints as well as business need. Implement a subset of these assets and examine how the integration works with multiple assets being utilized by a business process, service capability, or an application.
  • Establish a environment for testing these reusable libraries outside the main application in order to facilitate reuse on subsequent projects. This is key for sustaining your future efforts – provide automated tests and an environment (a sandbox server to begin with will suffice) that allows developers to prototype using reusable assets.

Most likely, with a pilot you will learn a lot – a lot about how developers actually use reusable assets, what challenges come in the way in terms of project deadlines, lack of documentation, and unclear assumptions that the asset makes about the domain and even the operating environment. This exercise would also make it painfully obvious the technical debt various reusable assets are carrying – fixes, refactorings, and enhancements that are needed for reuse to be successful. This would be valuable feedback to use – work with your teams to flush out these issues and get to a working mode that allows for iterative and incremental delivery. Remember – your reusable asset doesn’t have to be perfect only constantly aligned to business needs.

Overcoming Technical Challenges With Adopting Agile – New Article

November 14, 2009

infoq Article on overcoming technical challenges with adopting agile methods was recently published at infoq.com – do check it out here: http://www.infoq.com/articles/technical-challenges .

The article covers:

  • setting up developer environments
  • automated testing & continuous integration
  • Defining the meaning of “done” in your environment.

Systematic Reuse Success Factor #2 – Ease of Integration

July 18, 2009

An often overlooked aspect of systematic reuse is integration of reusable assets with applications, processes, and services. Most teams focus on building a large inventory of reusable assets – services, objects, frameworks, domain specific language libraries. While that is necessary it is not sufficient for succeeding with systematic reuse. One essential ingredient is ease of integration. What do i mean by that? Specifically:

  • Evaluating the requirement and making a determination whether an existing asset can fulfill the need (as-is or with modifications) or a new one needs to be developed.reachingout
  • Address risks with integrating with a reusable asset (meeting SLAs, solution complexity, etc.)
  • Sharing information on available interfaces (is there a java interface? a web service?)
  • Providing code samples and integration design patterns
  • Provide comprehensive list of error codes and error handling recommendations – if a service throws a particular error what should the consumer do? are there specific business errors or data validation errors that the consumer needs to be aware of?
  • Ensuring the consumer doesn’t starve the reusable asset’s resources. This is essential for services based reuse where multiple consumers are invoking the same service capability.
  • Assistance with testing the integration (provide test data, unit test code, as well as utilities to test response time/throughput)

You can build up a service catalog and magically hope to achieve high degree of reuse and you will most likely be disappointed. Bottom line – reach out to your consumer and help them succeed. Make it easier for them to evaluate, integrate, and test. Slowly but surely your teams will start coming to you as opposed to you trying to ‘sell’ them on the value of reuse!

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

%d bloggers like this: