ABAP unit: test classes part of prod. code

Question

Hi all,
I've read <a href="https://weblogs.sdn.sap.com/pub/u/266">Thomas Weiss</a>'s weblog: <a href="/people/thomas.weiss/blog/2004/12/17/a-spotlight-on-abap-unit-part-1 Spotlight on ABAP Unit Part 1</a>.
I posted a question there, but apparently Thomas can't answer at the moment, and since I'm impatient for getting someone's opinion, I reckon we can discuss that topic here  :^)
As explained in the <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/c1be1003-0701-0010-3795-f87160de6483">NetWeaver Developer’s Guide Using ABAP</a>, the test classes are part of the program under test (PUT):
<i>In ABAP Unit, test classes are part of the production code of the TU. This avoids problems arising from the test code being separate from the production code:
- Programs and tests must be kept synchronized.
- You have to ensure that the test and program code are transported together.
- External test code only enables black box tests with an outside perspective of the tested program.
Since the test code is part of the production code, it is easy to keep the unit tests and the
production code up to date if the latter is changed.
Although the test code and the production code are transported through the system landscape, ABAP unit tests do not increase the load on the production system. By default, the test code is not compiled in the production system. Therefore, the test code can never be executed in the production system.</i>
On the other hand, this idea is quite different from what suggested by other unit testing frameworks.
For instance, the documentation of <a href="http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html">Test::Unit - Ruby Unit Testing Framework</a> reads:
<i>It‘s handy to collect a bunch of related tests, each test represented by a method, into a common test class that knows how to run them.
The tests will be in a separate class from the code they‘re testing for a couple of reasons. First of all, it allows your code to stay uncluttered with test code, making it easier to maintain. Second, it allows the tests to be stripped out for deployment, since they‘re really there for you, the developer, and your users don‘t need them. Third, and most importantly, it allows you to set up a common test fixture for your tests to run against.</i>
Regarding the advantages outlined by NetWeaver Developer’s Guide:
- Programs and tests might be kept synchronized even if they don't belong to the same unit of code.
- Moreover, you could assure that the test and program code are transported together by saving them in the same package.
- And quite frankly, I don't have a thourough understanding of the reason why external tests only allow <i>black box tests with an outside perspective</i>.
What are your opinions on this?
Regards, Davide

Answer 1

Hi,
when I started unit testing with JUnit I was quite surprised that SAP groups the tests with the production code. But now I actually really like it. It has a few advantages:
- Good tests serve as an excellent documentation so why not bundling them together.
- If you want to look at the tests they are easy to find.
- I write all my class tests as local classes. I found out that it really helps me to focus on writing tests only for the class under test. Sometimes it is quite easy to forget the "unit" and write integration tests again.
Regarding your question:
>And quite frankly, I don't have a thourough understanding of the reason why external tests only allow black box tests with an outside perspective.
Usually I would not use the term black box testing in this context. Maybe you mean that it is easy to access private attributes, methods when you group class and testclass together?
Normally black box testing means that you cannot look at the implementation of the code under test. So your tests are based on the specifications or if there is not one, on your common sense.
cheers
Thomas