I’ve been setting up debug tags for automated testing of a GWT-based web application. This involves turning on custom debug id tags/attributes for elements in the source of the app. It’s a non-trivial task, particularly for larger, more complex web applications. Recently there’s been some discussion of whether enabling such debug ids is a good idea to do across the board.
Currently the debug ids are only turned on in development and testing servers, not in production. There have been points raised that enabling debug ids does cause performance to take a hit, and that debug ids in production may lead to security issues.
What are benefits of doing this? Are there any significant risks for turning on debug tags in production code?
2
The performance penalty is not in the observable range. Enabling debug ids in GWT is as simple as turning on a inherits tag in GWT. It only is non trivial for some composed widgets or in case of custom logic for grids or tree.
- Build with debug ids and run selenium based automation.
- Build without debug ids and run manual sanity tests.
> What are the downsides of leaving automation tags in production code?
I agree with @Sachin Shekhar R that performance and space penalty is marginal.
The only problem i can think of is that bots can use your website much easier, if there are tags on your important input and output fields. if this can become a problem or not depends on your use-case.
At least the login and the customer registeration form should be protected agaist bots.
Those flags should really only be turned on in DEV but it seems like you are using QA as your build integration instance. PRD absolutely not. If there is an issue with PRD you need to restore it down to QA, if you have a project ongoing thats using QA then you build another set of instances.
I have to fight tooth an nail about this with most clients but segregation and proper promotion polices need to be put in place from the start. QA is intended to be a real world assessment of your dev assets with full data capabilities. DEV environments are disposable and PRD goes untouched.
You should never be modifying PRD directly unless an impact/downtime assessment has been done and its been approved. The best way to answer your own question would be to restore PRD into a similar environment and start running performance tests against it.
However its unlikely if debug flags are causing noticeable delays – its more likely the hardware those environments are sitting on may be underpowered or over burdened.
Keeping debug tags in code used in production environment is not a bad idea. Though, these should only be enabled as and when required, in case of customer issues etc., leaving debug mode ON on production machine is not recommended. Further if it is needed to implement debug mode, then debug levels should be defined, and upper level debug mode may be enabled in production environment with the possibility to change that level as and when needed.