Often, to simplify testing, I add UI controls that are only visible and enabled in debug build only. Or prepopulate mandatory input fields in debug build. Is this a bad practice? Assuming the release is tested too.

Main reason is to simplify fixing bugs - when the problem is in depths of your program, it's quite a pain to go through dozens of steps repetitively.

The way I did it so far is add "debug" button on the main form/page, leading to a form/page full of shortcuts to various places in the program.

This seems like a borderline code smell to me, so I was wondering if there are better ways.


This is not so much an indicator of bad practices as a strict test of your deployment process.

Obviously it is very bad if debugging controls, content, backdoors etc. get into production environments. But if they help you achieve the same business goal faster, they save the company real money. Therefore the crucial factor is to ensure that they cannot get into production code even by carelessness. Integration testing, automated builds, maybe even specific regression test that certain controls are not there can help with this goal.

Certainly debug-only code in general is too valuable to ban outright, merely because it might mess up production systems. Every change might mess up real data, the trick of software engineering is to be aware of risks and pressures and balance them properly.

  • "The way I did it so far is add "debug" button on the main form/page, leading to a form/page full of shortcuts to various places in the program." – user5226582 Feb 10 '16 at 13:36
  • @user5226582: The better practice is to drop the "debug" button and just go to the debug page by entering its URL in your browser directly (if that is possible in your setup). – Bart van Ingen Schenau Feb 10 '16 at 15:13
  • 1
    It doesn't have to be web-related. Also, the point of a single button (entry point) was to easily disable in release build. Was just responding to "better have a separate "debug page"" which is exactly what I did. – user5226582 Feb 10 '16 at 15:49

Debug code has been included in programs for practically as long as they have been written. The elephant in the room however is that your testing cycles are not against the version that will eventually ship . While finding some issues early might outweigh the cost of finding hidden bugs later, it is certainly a risk to consider.

You also need to be careful that any code you add can't be used as a backdoor to get round any built in application security you may have.

If your test data set up is looking like it might be labour intensive, then look into automated unit testing. For repetitive tests, you should ideally be looking into this anyway.


Depending on the design of the application your approach might be necessary.

I find that the best way to debug UI applications is to be able to initialise it with a state from the beginning (for example from a JSON dictionary). Then the only debugging entry is the initial state. This is fairly easy if you develop web based applications and very easy if your UI is always constructed from the state (e.g. if you use React-like APIs).

If you absolutely can not avoid having debugging controls, I recommend isolating them from the rest of the application so the removal is trivial.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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