Introduction Recently, I spoke with a Technical Fellow at my organization who is passionate about CI/CD practices. Coming from an SAP background, I often feel SAP’s testing tools are incomplete. However, the organization aims to enable zero-click deployment, which brings certain challenges.

Concerns with Zero-Click Deployment in SAP During our discussion, I shared my concerns about zero-click deployment, especially regarding untested code. When asked if I believed there were untested areas, I confirmed this and explained the issues with SAP’s mocking capabilities.

Problems with SAP’s Mocking Tools SAP offers a test double framework, but I find it lacking. While you can mock SQL queries and function modules, mocking class methods is tricky. You must use workarounds like inheriting classes and overriding methods in local classes.

Missing Mock Data Libraries Another issue is the lack of proper mock data libraries. Instead, developers must hard-code every variable, structure, and internal table they need for tests, which is slow and frustrating. Writing AUNITS tests is time-consuming, yet our organization requires 70% code coverage.

Other Testing Limitations in SAP Some SAP features make testing harder:

• ALV functionality includes a lot of code that can’t be tested.
• Selection screen events aren’t easily testable.
• We haven’t started writing AUNITS for Elements-based Fiori applications yet, which adds to my concerns.

The Fellow’s Suggestions The Technical Fellow introduced me to the idea of TANSTAAFL (“There Ain’t No Such Thing As A Free Lunch”). He acknowledged these challenges but encouraged me to write custom libraries for generating mock data and improving test coverage. While this is a big task, he believes writing technical papers about these issues will help clarify ideas and invite team collaboration.

He also explained that CI/CD is less about open-source development and more about ensuring consistent deployments to track cycle times and measure developer productivity.

SAP vs. Open Source Development I found it hard to clearly express my concerns because SAP development is different from open-source environments. Even simple API consumption in SAP requires extra steps, such as:

• Managing certificates securely.
• Passing certificates to external API calls to retrieve OAuth tokens.

Right now, I’m unsure how to call external APIs through our corporate proxy, but I believe a solution exists. In contrast, Node.js or Python applications make this process much easier.

Platform Independence and OpenStack The Fellow advised avoiding vendor platform dependencies and instead building requirements using OpenStack. He explained that teams are organized to solve specific problems with specialized tools. He provided an Workday as an example where we broke platform dependency, I pointed out that it’s also a vendor platform. While he agreed, he said ideally we would avoid such dependencies.

I argued that full isolation isn’t easy since SAP’s interconnected functions require major rollout changes. However, from his view, computer science is universal — there’s no separate “SAP computer science.”

Recommended Reading The Fellow suggested I read Clean Architecture by Robert C. Martin. I sheepishly admitted that I bought the book a couple of years ago but haven’t read it yet.

Exploring Agentic AI and Browser-Based Agents We also talked about Agentic AI, where I mentioned using Playwright scripts for platform enablement. However, the Fellow stressed that solutions should start with clear problems, not vice versa. He warned that browser-based agents can be unreliable and recommended focusing on backend services and APIs instead.

While he wasn’t completely against browser-based agents, he suggested using them sparingly. For query-based agents, he advised building them on the data lake side instead of SAP to reduce platform dependency.

Final Takeaway: Think Like a Walmart Engineer The Fellow encouraged me to think like a “Walmart engineer” — someone who designs solutions with an end-to-end view and addresses real-world business problems.

Conclusion This conversation helped me see CI/CD in SAP from a new angle. It reminded me to focus on clear communication, technical clarity, and problem-driven development. Moving forward, I plan to apply these insights to improve my development approach and align better with organizational goals.