Efficiency in development: Test Data in development client

[JaschaS]

Hi SAP community,

I am a developer and often encounter a problem that slows down my development process: Bad or no test data in my development client. I would like to know how other companies do this.

The problem is related to our system landscape:

• One development system (DEV) with client 100 for development and customizing and one client 101 with barely usable test data
• One quality system (QUA) and of course one productive system (PRD)

For almost all development changes I make, I have to transport to QUA in order to test. In the worst case, This can take 15 minutes of waiting, because that's the import frequency into QUA. This frequency is not increased because of fear of overlaps when one big transports takes longer than the interval of 15 minutes. Is this a reasonable fear? Please share your experience for this too.

If I'm lucky and there is usable test data in the DEV system, I still cannot directly set break-points in ADT, because they are set in client 100 and test data is in 101. So I need to logon to client 101 in order to test.

This is very inefficient and frustrating. How is your setup, how do you deal with this?

SAP's recommendations I have found so far are also not unanimously. Sometimes, SAP recommends a "golden client", but in other online resources it's called an outdated concept.

During our transformation from R/3 to S/4, our colleagues tried to merge client 100 and 101 into one client. But there were some hurdles that apparently could not be overcome - I was not involved in the details, but the client seemed to be "not consistent".

Unit Tests would be a solution, but are not feasible with all our 20+ year old legacy code and without dedicated time to build them.

Looking forward to your experiences!

[Ryan-Crosby]

In my first job working with SAP the company only had one client for each level in the landscape, and any reference to a "golden" client was for the reference client 000.  Development tasks were generally very efficient because there was always usable data for conducting the necessary unit tests.  When I had come to my new company they had an ECC environment also with a single client in each level, but the SI had suggested a golden client for the S4 transformation (at the time I had never heard of it in this type of arrangement).  What I observed immediately is that any development task became slower, especially if it required any additional tinkering with customizing... "Let me SCC1 that over".

The general argument that I would hear is that if we have a "golden" client we can always reverse customizing if data doesn't exist, but it becomes a problem otherwise.  Not a particularly well thought out argument because anything can be reversed in a development system, even if it may take a little extra time.  Seems to be more a fallback crutch so folks can fudge around or experiment in customizing instead of knowing what they need to configure.  There's a place for that and it's called a sandbox which can be blasted by a refresh at any time.  

Regarding being able to change anything in a development system - we had an instance of needing to update a wildcard certificate in STRUST in production because all certificate based communication was failing when our old certificate expired.  The problem was that a password had been entered into the .pfx by our previous SI and not recorded anywhere, and we are not able to contact the necessary person for several hours.  A short stint in the debugger and that problem was cleared without needing to open a ticket with SAP.

Fast forward a couple of years and the archaic concept of a "golden" client has been incinerated in our landscape.

Regards,

Ryan Crosby

[Sandra_Rossi]

If I understand well, your biggest problem is that you're missing test data in DEV. Ask the client to copy data from QUA. My current client and even colleagues don't want to copy because they think it will erase the program versions in DEV, which is wrong (the versions have to be backup and restored -> no loss).

[christoph_weyd]

If you have the space simply create a  SBX system from QA. Open SBX for development, create your programs and when ready copy or transport to DEV

[JaschaS]

@Ryan-Crosby Thanks for sharing your experience about the golden client, it underlines my assumption about it.

@Sandra_Rossi: Thanks! We asked already multiple times to copy data from QUAL or PROD to DEV, but it is being put off with "DEV is not sized for it" and "PROD import to DEV will make DEV crash because of customizing differences, leading to an inconsistent client". Have you faced the latter too, and if yes, how have you overcome it?

@christoph_weyd Thanks, but I think another system will be even harder to argument for.

[Sandra_Rossi]

nope

[matt]

The Golden Client concept works great for configuration but is rubbish for development because of course what we do is client independent. However, as developers, we're way down the food chain from the functional people, so they get what they want. 🙂

I've worked in many environments. Where there is the Golden Client nonsense I create two different workspaces and run two instances of eclipse. One is in the development client, one is with the client that has data. If this is the way things are done, it is the responsibility of the functional team to create test data. Because I have two different instances, it's easy to switch between. Just remember to hit F5 on the test client source code to ensure that when debugging you get the right source code.

I'm in this situation now. I've debugged in 200. I'm now going to take that data and use it as the source of my unit tests in client 100 using test doubles and mocking. This way, I can 99% probability fix the issue in 100.

In other places we've used Transports of Copies for interim changes and automatic import into the test system for testing (so the the test system is a copy of production). Workbench requests are only released when the work is verified tested. This is how CHARM works.

In all cases it is the functional team who are responsible for creating test data.

[JaschaS]

Thanks for the insight, @matt.

Do you manually take over data from the test client into your unit tests or do you have a more efficient way?