Clarify test features in product code

[pokrakam]

Closes #247

[pokrakam]

Thanks for your comments. I had a hard time deciding the "feature" term myself so I thought I'd put it out there for comments. The reason to call it "test features" was to make it broader than just code. I've seen all sorts of things like DB switches for testing, dummy tables, test switches in config tables, ECATT integration. The worst is the deeply integrated variety that transcends calls and spans objects, where we're almost talking about test architecture woven into the product.

But you are right all of this has a code component somewhere. Just to throw another term into the mix, the Clean ABAP book refers to this as "intrusive testing concerns".

I had the same thoughts as you about the application domain aspect, which is why I used "unit test features" and added the bit about application test features being OK. I felt "test code" was a little too generic in this regard and could be interpreted as don't do test postings or test runs.

Both of these have pros and cons, and I'm fine either way. Shall we see what the maintainers say?

[jdgx]

Yes, I can also live with the other options. Let the maintainers decide. To throw in some more options:

• Don't mix test code with production code
• Test Logic in Production

[pokrakam]

• Don't mix test code with production code

I like this wording, and good blog too.

[N2oB6n-SAP]

I support all proposed changes (using "production" everywhere and clarifying that "test" refers to automated tests).

Only thing that is left is the tiny grammar mistake that I believe to have spotted.