I would avoid building an api framework from scratch unless commercial products can’t meet my needs. Ideally, I’d like an open source product which can automate many things - api, desktop web, mobile, mobile web etc., handle reporting and more. So, in theory, we could potentially tweak the OSS framework to meet any custom needs. But, the downside is lack of dedicated customer support.
I’d bet that frameworks and their components are essentially repeated across many companies, i.e. reinventing the wheel in cases where a generic wheel would suffice.
It looks like the Karate framework by Peter Thomas (Intuit) is a unified framework which will reduce or eliminate the need for custom frameworks in many companies. Apparently, in Karate, you can swap out components like web auto (selenium), test framework (testng), reporting tool (extent reports), CI (Jenkins) etc. with the tools of your choice. I’ve wanted to try Karate, but just don’t have the time. Anyone here used it?
My 2 cents:
The problem with custom frameworks is that you need a highly skilled & dedicated team to maintain them. So, you are heavily dependent on that team & you have to smoothly handle departures of crucial members. If your company cannot offer as much growth, variety & pay compared to, say Amazon, then those engineers will leave you soon. You might not be able to replace them easily or with someone good.
OTOH, the challenge with commercial tools is that they try to please many customers. The advantage is that you might get a test tool which has features that you never even anticipated you’d need (thanks to the large customer base). But, the downside is that the tool might be developed to suit bigger customer’s needs which might not match yours. Bigger customers are often laggards, wasteful, bloated and bureaucratic i.e. a graveyard of ideas & dreams. Their requirements might take the testing tool backwards.
One suggestion to all companies who make their own automation frameworks on their own or with the help of consulting companies (often of questionable intent). Please try to make your frameworks open source, the earlier the better. This might encourage its developers to be more careful about their code. Those who consistently produce bad code will be called out by the public on github and will (hopefully) shy away from the automation team or maybe from even interviewing with the company. Does this idea sound good? Should it be a separate question? The downside is that good candidates who underestimate themselves or don’t want public attention might shy away from the interview/team.