-
Notifications
You must be signed in to change notification settings - Fork 443
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify test features in product code #254
Conversation
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? |
Yes, I can also live with the other options. Let the maintainers decide. To throw in some more options: |
I like this wording, and good blog too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Closes #247