OpenESPI testing

25 views
Skip to first unread message

Marty Burns

unread,
Feb 17, 2014, 10:46:53 AM2/17/14
to greenbutton-dev, energy...@googlegroups.com, John Teeter, donald...@reminetworks.com, Ron Pasquarelli, Gaylord Miyata

The current set of tests show that there are issues with either the tests or the software behavior and we need to determine which.

 

Ron has some results to show on the call today so we can resolve.

 

As I understand it, the problems are two-fold:

1)    When you do a POST, you can’t do a GET of the results because you don’t know the IDs that will be assigned

2)    The current implementation won’t instantiate links for collections that are not yet populated. That is if you POST a UsagePoint, there will be no ElectricPowerUsageSummary link until an ElectricPowerUsageSummary is added.

 

If this is desired behavior, the tests will have to be modified to accommodate. If it is not, the software updated.

 

Note that the autoincrement nature of the table IDs assigned adds complexity to accepting an addition to a collection (such as a new IntervalBlock) since the mapping between source ID and destination ID will have to be made. Also, the operation of the sandbox which needs to be repopulated often will have a dependency of always having to have things in the same order and same composition. Otherwise the assigned links will change.

 

Marty

Teeter, John

unread,
Feb 17, 2014, 11:26:51 AM2/17/14
to Marty Burns, greenbutton-dev, energy...@googlegroups.com, donald...@reminetworks.com, Ron Pasquarelli, Gaylord Miyata
1 – A POST is  returning the posted entity so that the SELF href is readily available to the application using the RESTful interface. I caution the testing against assuming/anticipating anything with respect to the particular form of the SELF href, only that a GET to that href returns the anticipated object. In particular, making assumptions about the form of any of the {resourceId}s should (IMO) be avoided and testing against opaque URIs should be the goal (IMO).

2– I had assumed it optional re: the production of <link rel="related" …> to empty collections as the DMD validator does not require them?

3 – we should get away from using the sandbox (a public machine) as the testing/integration machine (re: your final comment below). There are two distinct (and non-compatible) needs that need addressed. We need to finalize a path toward a testing/integration deployment.
jt

--
You received this message because you are subscribed to the Google Groups "greenbutton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to greenbutton-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Reply all
Reply to author
Forward
0 new messages