[erlang-questions] common test, test_server and ct_hooks

[Tim Watson]

Hi Peter

On 13 Aug 2012, at 13:38, Peter Andersson wrote:

> Hi Tim,
> 
> When a test case times out, the test server control process kills the
> test case process, on which the Config data is known (it's last
> returned by init_per_testcase/2 on the same hanging process). The
> result is that the latest Config value is unknown when the call to the
> post_end_per_testcase hook function takes place. This is not a bug as
> such (and OTP-9594 is a different issue), but it's a limitation for
> sure.

OK this makes perfect sense.

> There are 2 possible solutions to this problem:
> 
> 1. You keep saving the last known Config data (or at least your
> relevant subset of it) in the hook state. If the test case times out,
> you can restore the data from there. No need to use an ets table. You
> will be able to restore the Config data that init_per_testcase/2 was
> called with, but not the final value that was passed to the test case
> function.
> 
> 2. Common Test gets updated so that the control process saves the last
> known Config for a test case so that it can be restored and passed to
> the post_end_per_testcase hook call. The result will be the same as #1
> above, but it will make it easier to implement the CTH callback
> module. It might also be possible to have the test case process send
> the Config data to the control process after init_per_testcase, so
> that the very latest Config can be saved and restored. Implementation
> of this can be somewhat tricky because of parallel test case groups -
> but certainly not impossible! ;-)
> 
> I'd be very happy (well, sort of) to implement #2 above. Will #1 be an
> ok workaround for you until #2 is in place?
> 

Yes #1 will work fine for the time being. In fact, as it's mainly a pid that I'm tracking (so that a gen_server can be instructed to tear-down and stop) I've opted for local name registration as a workaround for the time being. At some point I'll have to think about name clashes, at which point I'll need #2 but for now there aren't any as the server name/id is tied to the suite, group or test-case name anyway. 

> I know it's usually not appropriate to be talking about doing #1 and
> #2, but in this context you know what I mean! :-)
> 

Absolutely and that sounds like a good phased approach for my needs. Thanks again for getting back to me.

Cheers,
Tim 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120814/165e9f14/attachment.bin>