The problem has been discussed, via email. The page currently is incomplete ..
Specific questions:
Proposal Type: is this not simply an improvement? Ie defining a mock configuration, and then using it to produce test cases?
Implementation
- the details indicate that a mock geoserver instance will be needed. How many classes must be stubbed? I understand the answer depends on how the configuration proposal goes ... can we have an answer either way?
- could we not implement this against a default configuration? Packaged in a zip file in the usual manner? But only used when running the test cases,
Risks:
Having to adjust to a different configuration abstraction seems to be the major risk (enough that you would like this work scheduled afterwords). Do we have any risks in terms of QA?
The problem has been discussed, via email. The page currently is incomplete ..
Specific questions:
Proposal Type: is this not simply an improvement? Ie defining a mock configuration, and then using it to produce test cases?
Implementation
- the details indicate that a mock geoserver instance will be needed. How many classes must be stubbed? I understand the answer depends on how the configuration proposal goes ... can we have an answer either way?
This is something I'm interested into as well
- could we not implement this against a default configuration? Packaged in a zip file in the usual manner? But only used when running the test cases,
Jody, testing is used when it's relatively fast. Starting up the
config system is not, requires parsing XML files.
Plus, how many testing configs would you have? If one, then it's going
to be really big (and thus very slow to load), otherwise you would
have one per test, thus potentially hundreds.
Mocking allows us to have a simple, controlled configuration per test,
and have fast testing as well.
The problem has been discussed, via email. The page currently is incomplete ..
Specific questions:
Proposal Type: is this not simply an improvement? Ie defining a mock configuration, and then using it to produce test cases?
Implementation
- the details indicate that a mock geoserver instance will be needed. How many classes must be stubbed? I understand the answer depends on how the configuration proposal goes ... can we have an answer either way?
This is something I'm interested into as well
It may just be a straight numbers game;
- could we not implement this against a default configuration? Packaged in a zip file in the usual manner? But only used when running the test cases,
Jody, testing is used when it's relatively fast. Starting up the
config system is not, requires parsing XML files.
Plus, how many testing configs would you have? If one, then it's going
to be really big (and thus very slow to load), otherwise you would
have one per test, thus potentially hundreds.
Mocking allows us to have a simple, controlled configuration per test,
and have fast testing as well.
Thanks Andrea, just wanted to get that out into the open (and perhaps on the page?)
The next obvious question is ...
- Do you think we could just produce the DTO objects to configure the real Data module, limiting the configuration to just what is needed for the test.
I am hard pressed to see how this would be more code then that needed for mock object approach. Your point about speed still stands.