Real TDD example?

[Private_Member_49934]

Hello experts and Gurus out there!

I am looking for a REAL practical  program which makes use of ABAP UNIT. Any SAP Standard Report ( Should be simple to get started with) which can be checked to see how the test case be written when majority of the program is based on selects .

  - Sir any help please!

I am desparate to get started with ... and get it introduced to my project. Though I can get started with but am not able to practically put it into any existing report in the project.

[rdiger_plantiko2]

Hi Kunar,

have a look at the test report ZZ_ADD_TWO_NUMBERS for a really simple example:

http://scn.sap.com/thread/3215347

Also have a look at my Wiki which answers frequent questions:

http://wiki.sdn.sap.com/wiki/display/ABAP/ABAP+Unit+Best+Practices

Regards,

Rüdiger

[Private_Member_49934]

Thank You !

I had gone through your blog. it's really wonderful. It's already on my bookmark and I am sure i will keep refering back to it once i get used to abap unit.

Regarding the ZZ_ADD_TWO_NUMBERS, The example is good to begin with and I am quite comformtable about writing the class and method.

However, All over the internet and scn I find example showing the use of abap unit with standalong logic and I am more interested in seeing it's utility in an ABAP report whose purpose is to fetch data from,say, 5 tables, and based on various if and else finally show the ALV to a user.

How is abap unit gonna add any utility in such cases ?  I had seen in your blog that select should not be tested using ABAP unit, but let's face it -- Majority of regular run support imovlves such reports . Should such report have no testing class?

Can you share any real program where abap unit was used ?

[rdiger_plantiko2]

Hi Kumar,

thanks for your feedback.

ABAP unit is not designed for testing database access, and user interfaces. Actually, one has to make some effort to factor out DB and UI, so the application logic can be tested isolated from the rest.

In a good design, the code doesn't mix SELECT statements and logic. Old-fashioned coders try to avoid modularization, partially because of laziness, partially because they want to have one unit, starting at line 1, and having everything completed on line 10'562... This is a very bad starting point for unit tests.

Writing testable code implies working with many code units, each containing only few code lines, but with clear responsibilities and defined input/output.

When writing new code: Start from the beginning by separating theses three layers from your own application logic

• DB,
• UI,
• API calls of other application logic

As for DB: the methods of your application logic could get the DB data as import parameters. Then. in your tests, you can provide these parameters with test data.

As for UI: The UI should be an own program or function group, which only calls your application logic.

As for API: If you call application logic from other sources - e.g. function modules containing application logic, you maybe don't want to include that logic in the test of your own unit. In this case, you can use a stub / dependency injection to substitute these calls by test code while the unit test is running.

>Can you share any real program where abap unit was used ?

Sure. Have a look at my JSON parser:

http://bsp.mits.ch/code/clas/zcl_json_parser

In the drop-down menu, choose "ABAP Unit Tests". Actually, I had created these tests one after the other, while developing the class zcl_json_parser.

A parser is a good example, because it contains only application logic. Also, mapping tasks are very grateful code for unit tests.

If you want to have automatic tests which include UI and database - i.e. integration tests - then unit tests are not the right tool for you. For those tests, I use eCATT's, HP QuickTestProfessional test, and Selenium for Web Interfaces.

Just keep in mind that unit tests and integration tests are two different things, with different purposes.

Kind regards,

Rüdiger

[wol]

Hello Kumar,

I also think it´s best to separate e. g. DB and Output-Logic.

But to start Unit Testing at all you could for example define the report incl. Database Access as the 'Unit'.

I. e. your Unit Test would be a local Testcalss of your report.

Reports are a bit complex to call as a 'Unit'. But its possible via Submit and get the report list to check if the list contains your expected data.

I would assume this as a starting point; next steps should be separation of the DB, Business Logic, GUI as said before.

Regards

Stefan

[rdiger_plantiko2]

If you have a report, then you should also have some modularization, let it be form routines or methods of local classes. Having no modularization units at all is out of any serious discussion.

But if this is the case, you can call those modularization units (form routines, local class methods) from your unit test class. That's better than submit, because you can receive results as parameters directly (instead of using ugly workarounds like IMPORT ... FROM MEMORY, which would be necessary when using SUBMIT ... AND RETURN ).

[Private_Member_49934]

I sorry that I don't subscribe to the Idea of using test case to submit the report and check the out...

Former Member  Thanks for that test program. I will go through it. In the mean time time I tried to do a where used on CL_AUNIT_ASSERT and I was suprised to see that SAP is suggesting something which they themself not follow? Only 33 fm / class with test class are there!!

Anyways, coming back to the original concern for this thread, I found that  CL_ABAP_DYN_PRG severs a real good example for someone starting with ABAP Unit.

However, I am still skeptic about it's utility in case of a report program. I would write a test report and would post it here to check the differenc between your approach and what I consider can be good. I would request your input for that.

[rdiger_plantiko2]

Hello Kumar,

> CL_AUNIT_ASSERT: I was suprised to see that SAP is suggesting something which they themself not follow?

>Only 33 fm / class with test class are there!!

1. The where-used list does not necessarily find all hits in the code. The index on which the where-used list relies is generated only for programs that have been explicitly generated in your system (for example when they have been used).
2. Meanwhile, there is a successor class CL_ABAP_UNIT_ASSERT (but CL_AUNIT_ASSERT can still be used, it simply delegates to the new class).
3. Good techniques take a while until they are established. Why should this be different at SAP. Think of object-orientation. It goes back to SIMULA (1967), and still I know programmers considering objects in programming as newfangled bells and whistles.

>However, I am still skeptic about it's utility in case of a report program.

The better your program separates the UI (selection-screen, parameters, output list) from its actual processing logic, the better it is testable... the better it is at all! I found that making my programs better testable, actually always improved their quality.

Regards,

Rüdiger

[Private_Member_49934]

Thanks a lot Rudiger.

I working on basis 701 and so CL_ABAP_UNIT_ASSERT is not present in out system.

I understand that the where used is not 100% true but I think it should be fairly accurate.

"Good techniques take a while until they are established. Why should this be different at SAP." - I agree. Hope I will buid up my skills for these good techniques.

By the way, I generated a local test class in su24.I found that it generates to method

1) setup ( I assume it is for the purpose of setting up test data)?

2)  teardown - Now what is this? I believe there is some theory and strong purpose behind that.. any link where I can read about it?

[wol]

The suggustion with checking the report result was because my opinion is not to check any private things but the the result iteslt. So if you want to test a report you have to check the output of it.

As said, if you live the approach to check the result itself.

Regards,

Stefan

[former_member183804]

Hello Kumar,

the report "RS_AU_DEMO_FIXTURE_PATTERNS" tries to demonstrate the idea of setup() und teardown().

The general concept is explained more decently at http://xunitpatterns.com/Implicit%20Setup.html.

Hope this clarifies the idea

  Klaus

[former_member189009]

Hi Kumar,

    I also come across this kind problem, I try TDD, but when my method come to select , I don't know how to finish the unit test ,have you find the real TDD example now ? I am appreciated if you can shave with us.

Best Regards.