consensus is not to do it this way. closed. On Jun 29, 2:53 pm, Daniel Clifford <[email protected]> wrote: > Hi Mads, > > The idea was indeed improved testability. > > Some of the tests we have to verify that internal event happens in the > runtime are fragile. I have run into this with my current work on unboxed > double arrays, but there are plenty of others examples. I would like to be > write specific unit tests (not performance tests) to verify edge cases of my > logic. But my tests will always pass with the auto-unboxing doesn't kick in > at all, making the tests useless. > > This actually happened yesterday... somebody checked in a change that > accidentally disabled the conversion to double arrays, and my code no longer > got called, but all of the tests still passed. I could add a forcing > function to cause the unboxing to happen, but then I can't actually test the > logic which is intended to trigger the transition in the first place. I > could write separate performance tests for each edge case, but that smells > way too heavyweight and doesn't seem right either. It seems like > whitebox-style testing in that case would be more robust and allow me to > write simple, clear tests for the edge cases. My suggestion to Yang was that > counters seemed to be a good mechanism to provide the needed > instrumentation, and I didn't really see a downside, since there seem to be > a fair number of counters that have been around for a while. > > Danno > > > > > > > > On Wed, Jun 29, 2011 at 5:22 AM, <[email protected]> wrote: > > I'm not sure I understand why we would want to expose counters to > > JavaScript? > > > Counters is an internal programmer tool that we use to gather statistics > > for a > > while and then delete again. I don't think we should do testing at that > > level. I > > would test behavior in tests and performance in benchmarks. If we are > > making a > > change that improves performance I think we should create a benchmark that > > shows > > it to stop us from regressing. If we want to make sure that a test hits a > > certain state, we should add functionality to force it instead of relying > > on > > counters I think. > > > There might be compelling use cases that I haven't thought of? :-) > > >http://codereview.chromium.**org/7281007/<http://codereview.chromium.org/7281007/>
-- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
