How to ensure unique session Ids in test cases

Question

Im trying out Spec Explorer and have begun creating a model copying a lot from atsvc example.
My main difference is that in my model job/session ids can't be reused after going to an end state but I don't find a way to enforce this.

I have three actions Reservation, Capture and Cancel (in my first limited scope).
Reservation uses a unique ID and Capture and Cancel can only be fired if a reservation exist.
I use a mapContainer and reservation checks so that the sessionID don't exist. 

Limiting the model to only 1 session ID I expected to get only one test case, either reservation->Capture or Reservation->Cancel but I end up with two of them both making a reservation with ID 1 and then cancel or capture it which would fail if I run it against the implementation.

I know that this model is of limited use but could some one explain how to model what I look for. I don't trust my model until I understand this. 

 

 

 

Answer 1

Hi Phosforos,

Models such as the ATSVC use a pattern called Abstract Identifier. This pattern applies to cases where your model cannot predict the actual values of the IDs that the implementation will issue. So the test adapter is responsible of mapping between the abstract identifier (such as the 1 you see in your tests) and the actual ones created by the system under test. If you fully implement this pattern, it shouldn't matter whether you see repeated IDs in your test cases, as your adapter would map them to (distinct) implementation IDs.

Another relevant concept in this context is that of accepting states. They are states in your model where a test cases are allowed to stopped, leaving the SUT in a condition from which a (completely) new test can start. From what you describe it looks like you are allowing states to be accepting, although the implementation is not reset after they are reached (IDs are supposed to be unique across test cases). One way to overcome this problem might be to use the "LongTests" strategy (assuming your model loops, otherwise a single test case would be impossible), which ensures test cases will be as long as possible. However, the real fix should be to add an accepting state condition that prevents test cases from ending at a point where you don't expect the SUT to be re-initialized.

Best,

Nico

Answer 2

Hi Nico,

Thanks for taking time to answer.

Yes I can see how I in the adapter could clear the ID list so that I can have ID 1 mapped against different "real" ids during test time.
I have modelled an accepting state which is when all transactions are in an end state (captured or cancelled)

I have on purpose constrained my model to the smallest possible telling it to only use ID=1 just to see if the test cases produced is what I expected. I will later let the model handle the IDs and constrain on other input values.

If I want the list of IDs/sessions, together with transaction data,  to be kept and shared between test cases so that I can validate on the sum/number of total transactions how would I tackle this? Or am I trying to control the end result to much testing to many things at once?

 

Answer 3

Hello,

I am not sure if I understand your requirement, do you want to verify how many transactions are completed?

If so, I think every time the abstract Id is deallocated (the transaction is captured or cancelled), you can let an accumulator increase, then you can verify the sum of total transactions by adding a new rule:

[Rule]

static int Verify()

{

    return accumulator;

}

In your adapter action, you can return the real sum.

 

 

Answer 4

Hi,

Sorry if im not clear enough, I think that the core of what im asking is, is there a way to get test cases to share data and to react on this data if needed.

If the only way of knowing if the sum returned by the system is correct is if you know what previous actions was made. You either have to create very long traces or share data between test cases to cover all scenarios. ie after 100 captures you will receive a bonus.

So you check the sum when test case is started you execute actions and then recheck the sum to verify the outcome. If you only are aware of what happened inside of the test case the sum will be to large, but if you know the full history then you know that this was capture 100 and that a bonus was added by the system.

If I understand you both correct this should be put into the adapter and verified there?

 

 

Answer 5

Hello, there is no approach to share such data among test cases because teset case design is supposed to be order-independent. But if you can control the order of test case execution, you can verify the sum at the final test case.

Thanks,

Xiang