2

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?

Improve this question
2
  • 2
    You can end up with a lot of "It worked on my machine!" effect when all the developers are working in debug mode with effectively different code than what goes to production. Also you should at the least be running identical code in test servers that you're running in production, not deploying the exact bits that go to a production server to a test server first is a recipe for serious midnight pager calls
    – Jimmy Hoffa
    Nov 29, 2012 at 2:05
  • We have not observed this behavior after 3 years of GWT use with Selenium. We set up ids on all elements via User code ( ensureDebugId(String) in recent gwt was not available then ). We plan to migrate to ensureDebugId soon.
    – appbootup
    Dec 14, 2012 at 6:04

4 Answers 4

Reset to default
2
+50

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.

  1. Build with debug ids and run selenium based automation.
  2. Build without debug ids and run manual sanity tests.
Improve this answer
1 
> 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.

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.