> My only issue using this with things like JS, won't all that code still be loaded into memory giving a misrepresentation of the memory profile of your app?

Yes it will. The alternative for that might be a modular design with very loose coupling and using Inversion of Control. Then, the only change you would need to make would be in the Inversion of Control configuration to load either the test code or the production code. You could place all the debug and trace code inside a single unit and use an empty stub in production. This would avoid sending the test code to the client on the production environment.

I am not an expert in JS, please correct me if this is wrong. I'd do something like this (for checking pre-conditions in method calls):

function Assert(condition, message ){} // this module is loaded/included in production only

function Assert(condition, message) { if(!condition) alert(message);} // this module is loaded/included in tests only