• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Testing API Versions

 
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome Mark!

I skimmed the TOC and reviewed the "teaser" info available.  I don't see any references to API versions.  The concept of versioning is important to some folks in the Microservices/Web API world especially for larger implementations.  As you reference a large project related to the HMRC tax platform, I'm wondering if you have any tips/thoughts on API versioning as well as any strategies for testing various versions of the APIs.  
 
Ranch Hand
Posts: 238
1
Python Ruby Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I had the same dilemma, in my previous project it became so apparent testing a multitude of  different
API versions became a nightmare, unfortunately, we had to live through that.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Caveat: I'm just spitballing an idea, but...

The one thing that comes to mind is separating intent from implementation. From a user's perspective, they shouldn't have to worry about what version of an API they're using. As long as they can achieve the same goal, which API version is getting hit shouldn't matter.

From an tester's/implementer's perspective, it should be easy to switch from using one version to another by means of an abstraction mechanism, like an adapter. If I were to imagine what would make it easy to test different versions of APIs, I'd have a common "intent-based" caller that could take any version-specific adapter, make the API call through the adapter and check that the expected response is returned. If there was any condition that was specific to an API version, that would be covered in a version-specific test.

 
Author
Posts: 20
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Brian,

That's a fair point to make about the book in that it doesn't explicity discuss versioning with in APIs and how that impacts testing.

I think the reason I didn't cover it is because it depends on how version APIs are handled. My question would be are older versions of API still being worked upon or are they kept as legacy for end users *or* are older versions still being regularly changed and updated. I've experienced both and how that process works informed the strategy.

If older versions of APIs are not actively worked upon, but we still need to ensure that new changes don't impact older versions, then automation is an effective approach. Automation for me serves as change detection. I create specific, targeted, automated checks that aren't meant to exhaustively test each version but to cover the highest risks and key functionality that, if the automation reports failures back to me, I can then carry out further exploratory based testing to learn more.

If older versions are actively being worked upon. Then once again automation takes an important role because merging versions that have distinct changes in them to create newer versions has the potential to throw up unwanted changes. But additionally I would add testing API designs and exploratory testing to dig deeper into why we are working in a given way and to identify and explore risks as new changes come in. Basically treating any change to any version of an API as a new functionality that has to be explored rigourously to understand what is going on.
 
Brian Burress
Ranch Hand
Posts: 143
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mark Winteringham wrote:Hi Brian,

I think the reason I didn't cover it is because it depends on how version APIs are handled. My question would be are older versions of API still being worked upon or are they kept as legacy for end users *or* are older versions still being regularly changed and updated. I've experienced both and how that process works informed the strategy.



I don't have a current context to give you an answer.  I've run into both situations and sometimes at the same time - i.e. some older APIs getting actively work while some getting kept until older client versions get updated.  I would expect the older versions being more needed for legacy support of old clients as also in my experience is that API developers can help by designing changes to not break the contract, per se, in the first place in order to avoid any versioning of the API being needed in the first place which helps avoid multiple active versions.
 
Mark Winteringham
Author
Posts: 20
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You would hope most places would put older versions of applications into legacy/maintenance mode but I have definitely experienced the later, which was a real headache. If I could go back to that project though I would focus more on why that choice has many risks to it rather than try and plug all the gaps of the leaky ship with shallow testing. But reality can bite hard sometimes
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mark Winteringham wrote:Automation for me serves as change detection. I create specific, targeted, automated checks that aren't meant to exhaustively test each version but to cover the highest risks and key functionality that, if the automation reports failures back to me, I can then carry out further exploratory based testing to learn more.


I really like your balanced approach with automation and exploratory testing. I think too often, the testing practice teams follow do too little of each, manually testing what could be automated, thus leaving little to no time to do exploratory testing for things you wouldn't or can't automate.
 
reply
    Bookmark Topic Watch Topic
  • New Topic