end time error

[nickhorspool]

Hi Andreas,

Another new bug in the time stuff! The end time which is default 3600s, when changed returns a value of 2 to the back end. This happens all the time.

Can we put some unit tests in for passing the correct values from UI to the backend json file that goes to anuga.

Cheers
Nick

[jj0hns0n]

This needs to be separated into at least 2 separate tickets. 1 for the bug here with the end time, and 1 for unit tests in general.

We need unit tests for the entire process up to the point that the job is submitted to ANUGA. These tests need to validate that security is working properly, and that values passed through from the UI wind up in the json properly. Im not sure how best to test that what is put into the UI gets passed through to the api properly. Andreas, any ideas there?

[ahocevar]

Regarding the initial issue, I cannot reproduce it. The outgoing json always has the correct value for the end_time.

Regarding the unit tests: there are several ways to write automated UI tests, but all are very time consuming. My estimate for an initial test setup with TestAnotherWay (the test framework used for OpenLayers, GeoExt and gxp) would be 12 hours. A test case for the simulation parameters would be another 4 hours. For the other forms even more, because of their higher complexity.

[jj0hns0n]

I will give it a test, but for now, Im mostly just reading through all
these tickets and adding comments etc. Nick is off to a conference for
2 weeks, so I dont expect any urgency on any of this for the
forseeable future.

Jeff

On Tue, Jun 28, 2011 at 12:50 PM, ahocevar
[email protected]
wrote:

Regarding the initial issue, I cannot reproduce it. The outgoing json always has the correct value for the end_time.

Regarding the unit tests: there are several ways to write automated UI tests, but all are very time consuming. My estimate for an initial test setup with TestAnotherWay (the test framework used for OpenLayers, GeoExt and gxp) would be 12 hours. A test case for the simulation parameters would be another 4 hours. For the other forms even more, because of their higher complexity.

Reply to this email directly or view it on GitHub:
#53 (comment)

[nickhorspool]

The thing is the users are still using it as we speak. So the big problem is the STOP status, but saving is also high priority but at least they can run it.

N

On 29/06/2011, at 5:54 AM, jj0hns0n wrote:

I will give it a test, but for now, Im mostly just reading through all
these tickets and adding comments etc. Nick is off to a conference for
2 weeks, so I dont expect any urgency on any of this for the
forseeable future.

Jeff

On Tue, Jun 28, 2011 at 12:50 PM, ahocevar
[email protected]
wrote:

Regarding the initial issue, I cannot reproduce it. The outgoing json always has the correct value for the end_time.

Regarding the unit tests: there are several ways to write automated UI tests, but all are very time consuming. My estimate for an initial test setup with TestAnotherWay (the test framework used for OpenLayers, GeoExt and gxp) would be 12 hours. A test case for the simulation parameters would be another 4 hours. For the other forms even more, because of their higher complexity.

Reply to this email directly or view it on GitHub:
#53 (comment)

Reply to this email directly or view it on GitHub:
#53 (comment)