[BDDFramework] Assert result is different on runtime and debug

Forge Component
Published on 2018-09-28 by João Proença
13 votes
Published on 2018-09-28 by João Proença

Hi there, 

I am trying to apply BDD Testing Framework on My project.

But I am facing 1 problem that very hard to understand.

My problem is when I run a BDD screen normally, the result was fail even if the logic itself is success.

But when I run BDD screen again on Debug mode, the result was success as expected.

It is very weird and I can not debug to find the cause because it went well on Debug mode.

Do you have any clue or any suggestion to solve this problem?

I tried the following ways to solve but no luck for me.

 1.Remove browser cache

 2.Set sleep on beginning of [when] as 1sec. and [then] as 3sec. 

 3.Use commit transaction after any DB event end.

 4.AbortTransaction on TearDown

 5.Put all Data event into server action

I know that the detail is not enough, It you need more information, I will create a ticket instead.

Thank you in advanced.

Hi Chaiwat,

Any part of your code is a timer or BPT? Remember this are run asynchronously. This could be a reason why it works on debug because with breakpoints the asynchronously run faster than you click on continue debugging.



Hi Chaiwat,

The question Marcelo asked is an important one. Usually the sort of behavior you describe is related to asynchronous processing happening in the background.

Nevertheless, what version of the BDD Framework are you currently using? 

And could you by any chance attach a test eSpace for us to check the code where you are experiencing this behavior?



There is no Timer or Process that run asynchronously in the code.

We are using Oracle DB in on-premise environment. Could It lead to the asynchonous logic ?

BDD Version is 1.2.1

Outsystems Platform Version is 10.0.825.0

It seem like the commit transaction is not work when using inside Notify. 

Logic step are

1.Given: Update test data for begining the test

2.When: Update Given data by New data

3.Then: Check data (goal: check correct update) 

4.Teardown: Update Data again and commit (goal: to return data to initial) (Commit data it seem not run well in normal mode)

I will make a eSapce to be simpler and send it to you later.

Thank you for advice.

Hi Chaiwat,

What you describe seems to be a common scenario that from my experience should work in an Oracle DB. Nevertheless, looking at a concrete example should really help in figuring out what is going on, so please do post the eSpace.