Creating external locks for Unit-tests

[bernd_dittrich]

I would like to do some unit-tests considering external locks. As this is the locking class itself I would ideally like to create SM12 locks which look like coming form another LUW and then let my own locking fail. As this test the lock-class, I would like to really create the locks realistically.

The unit test is for a Locking class in a BOPF-based application.

PS: I know, is not exactly a unit test as it not only tests the coding, however I would like to use the unit test framework here.

[pokrakam]

As a matter of interest, how are you locking a BOPF object?

I tried to implement an explicit lock function in BOPF before, but it's an internal action and SAP actively blocks the use of those. So the only SAP-sanctioned way I am aware of is an exclusive use read.

Anyhow, to your question: If your lock service does the actual lock in a dedicated method, you can override this in your unit test and simulate locks. I have done this and it works well, the lock unit test class basically has the lock state and user as attributes instead of an enqueue. This does not do an enqueue at the database, but I think it's a reasonable assumption that we do not need to test that (Otherwise we might as well start testing SELECT statements and everything else).

[bernd_dittrich]

Thanks for looking into this! BOPF is doing the locking with it´s own logic, composing the enque arguments from node and keys. We already have an approach similar to what you describe to simulate a locking situation from application side, works well for us as well.

What I was looking for was more for testing the End-to-End locking process for cases where we have special locking logic, we kind of map lock in that process, and for that it would be nice to mock on the enque side itself, so that the complete BOPF-behaviour is covered as well.

[pokrakam]

A complete BOPF mockup can be done, have a look at /bobf/cl_sadl_entity_transact for an impressive unit test.

There are a few other nice gems around, look at classes of package /BOPF/TOOLS and so some where-used searching.

I really like the idea but effort vs priority equation didn't balance at the time I looked at it so I didn't pursue it further.

In our scenario we had to lock outside the BOPF framework anyway because access via the Gateway immediately releases the enqueue. So the lock service was within our custom BOPF framework (retrieve with enqueue, if successful then z-lock) . Via injection it is possible to supply a test service to the lock factory and thus cover an entire end to end scenario across several objects.