Ticket #141 (new fixme)

Opened 3 years ago

Last modified 14 months ago

variant unit test

Reported by: ichthyo Owned by: ichthyo
Priority: lesser Milestone: 0integration
Component: lumieraProc Keywords: QA
Cc: Blocked By: #738
Blocking: #283

Description

Note to @self: this got sidelined almost a year ago...

...which just again shows you should never defer writing tests just to "get ahead"

Change History

comment:1 Changed 3 years ago by ichthyo

  • Keywords QA added

when doing this, we should also cover the similar cases of lib::OpaqueHolder, which are actually based on the same code from access-casted.hpp, which would need to be covered by the unit test in discussion here. (I.e. put a value into OpaqueHolder, and then re-access it as a parent-type or through an automatic conversion). While we don't need this to get ahead right now, it seems rather likely to expect some hidden bugs in this code...

comment:2 Changed 2 years ago by ichthyo

  • Blocking 283 added

comment:3 Changed 14 months ago by ichthyo

really should do that....
I recall that at the time when devising AccessCasted, I had almost a complete unit test fixture in tool/try.cpp. Just I was too lazy to spend an additional hour or so to rewrite that into a real unit test. Damn it!

the Variant type itself could also use some revamp and straightening; especially as we have now all those opaque holder types; there is potential to share more code. I am still a bit doubtful regarding Variaint, but the assessment of benenfits has remained basically the same (special visitation scheme, no dependency on the boost metaprogramming library, which tends to bloat the debug compiled code, deliberately no thread safety and thus simpler and shorter code paths)

comment:4 Changed 14 months ago by ichthyo

  • Blocked By 738 added
Note: See TracTickets for help on using tickets.