API Automation Framework - how NOT to create another REST-Assured?

One of the things I’ve been doing at my new (relatively) job is working on a automated API testing (or checking to be more precise) framework. The system architects want a framework that is general and abstracted enough to be used across different projects.

Sorry if the questions seems a bit too broad, but, my main concern is not re-inventing the wheel since REST-Assured meets so many of the most common needs for testing REST-APIs. I’m just curious about opinions and similar experiences on what kind of maybe helper functions to make for stuff not covered by REST-Assured.

Is it even worth going in this direction?


I totally agree. I don’t like the attitude of “let’s create another framework”. There are already so many frameworks out there.

The question for you is here, what is REST-Assured missing for you and can you just not add it to REST Assured? instead of starting over?

Imho: I don’t think it’s worth making a new framework, a lot of companies will not maintain it anyways.


Next meeting with the architects - if I had the guts:


If you need your API tests to do something and the RA framework doesn’t cover it, it’s quite likely someone has already written something and put it in the public domain that can be used to extend RA. I’d always be googling before trying to write anything new, mainly because I’m a lousy coder… :grin:


Also to consider other existing API test frameworks as well, REST assured isn’t the only one, but it may be one of the best and most popular ones.


I’d take a step back and figure out why someone thinks they need a framework, and what “abstracted enough to be used across different projects” means. i.e. REST Assured is a pretty strong framework, what do they want above and beyond it?

That being said, I could totally seeing writing a library/module if there’s common functionality - i.e. authentication, URL building, environment/config management, but I’d much rather build these as individual components, than some monolithic framework - that is, all the REST testing would be in REST Assured, but many of the “test runner” type things would be built as components to leverage and re-use.

Even in this case, I’d be doing a lot of analysis upfront to figure out what’s actually common. “Frameworks” end up falling apart that they try to meet all the needs, and often, there’s enough one off use cases that it doesn’t make sense to have specific frameworks, but rather just some code samples/patterns that people can tweak for their use cases.


Those are really good points @ernie I spoke to one of the developers in my team and we came to a similar conclusion, we’re going to pitch the idea of making utility/helper methods instead of re-inventing the wheel by trying to make something which already exists.