ABAP unit: test classes part of prod. code

[Former Member]

Hi all,

I've read the blog post: Spotlight on ABAP Unit Part 1 by thomas.weiss.

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

[Former Member]

Hi all,

I've read the blog post: Spotlight on ABAP Unit Part 1 by thomas.weiss.

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

[former_member183804]

Hello Davide,

One thing regarding grouping tests in ABAP Unit. To group is an option and to my opinion a big adavantage while this is not possible with other unit frameworks.

Regards,

Klaus

[Former Member]

Does the grouping option allow the developer to group several tests in a group of tests that can be executed as a unit?

This is defenitly useful. Anyway I don't see any reason why grouping isn't possible unless the test code is put in the production code.

(BTW I reckon grouping is possible with Ruby's unit testing framework, as well)

Thanks, Davide

[former_member183804]

Well Davide,

maybe I should have used bundeling instead of grouping. The advantage to have tests and code under tests within one tranport (or deploy) unit is that there relationship is well defined on both have matching versions. These advantages could also be reached by other means but it is a very easy and comfortable way.

Bye,

Klaus

[former_member183804]

Hello Davide,

grouping in ABAP Unit is not done with written code but by data. With the aid of code inspector you can define object sets of program under tests togehter ABAP Unit and execute such a combination on regular base, e.g. via batch scheduling. It is slighty different to JUnit´s test suites but provide similar functionality.

Regards,

Klaus

[thomasalexander_ritter]

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