Is Testing and Debugging Both a Science and an Art

Debugging — Fine art or Science

People who accept been coding for some years might have faced these tricky situations, where one will say

• We take been trying to find the root cause of this upshot for the terminal 2 days…
• We are stuck for the last 2 hours, everything is correct, but the test is not passing..may be a third pair of optics will help
• Not having plenty logs to identify the problem expanse.,and so going through the entire code to figure information technology out..

So, what's going wrong in those to a higher place places. Why is it so difficult or time consuming to place the root cause of an issue? I have always wondered whether debugging is an Fine art or a Scientific discipline? Over years of tiring debugging sessions similar in a higher place, I take come upwards with some guidelines for myself, which will make this process like shooting fish in a barrel and efficient for me. I hope it helps you likewise.

How did I arrive at these guidelines?

Simple. I retrospect and run the entire sequence in my mind and will get a bespeak to annotation and carry on for later. It's just not plenty to detect out how you arrived at the correct path, it is equally important to find out where and how you lot got mislead.

OK, enough said about the problem argument, allow'southward get to the bodily guidelines. Disclaimer: These are not rules, but guidelines and likewise inclusive but not an exhaustive list. Also, I have not given any examples unless information technology is absolutely needed.

1. Nuts first:

Please don't start your debugging by setting up the entire system in your machine and endeavor to load data and reproduce the outcome. For all you know, it might non exist needed at all.

Have you ever wondered, how the tertiary pair of optics is finding the problems quickly? Magic? Not at all. As those eyes are new to the problem, it asks the basic logical questions, through which solution is unearthed. Many a times, asking unproblematic and bones questions is all that you need. Some sample questions can exist

Where is it happening?

• Does it happen in all environments?
• Does it happen in developer machines besides?
• When debugging a devbox unit tests failure, you can enquire "Are these tests passing in the build pipeline?". This will tell whether information technology is an effect with your local setup or not.

From when is it happening?

• From which build or date things started breaking? This will help you narrow down greatly. You can easily encounter the commits history and figure out the problem.
• Things can be Date related besides. Yes..you remember the tests which failed only from a item date?

What situations does it happen?

• What sequence of events leads to this?
• Volition it happen merely on heavy load, exist information technology data or cpu?
• Will it happen for all the users of the system?
• Will it happen only for a specific shape of information?

Have you taken the right build?

Many a times, our set might not have reached the testing environs boxes and we volition exist wondering, why my fix is non working?

Can we reproduce it?

If yous can't reproduce it now, then, your investigation should be mostly fourth dimension based and what was going on in the arrangement at that time, rather than searching for a lawmaking issue.

2. Logs can really help!!

Oops!!

Needless to say Logs are a not bad source of information for debugging. But, it is your responsibleness to collect as much logs equally possible and clarify them carefully. If there is a defect in the functional logic itself, then logs might not have whatsoever errors for you, merely it will certainly tell y'all the sequence of events which happened at that time.

3. Understand the functionality:

Many a times, you might not be completely aware of the arrangement and its functionality. So, instead of attempting a debugging by purely coding footing, try to go more than data about the system. This involves

• Reaching to the person who knows the functionality and asking questions to sympathize it better.
• Ask questions about Technical compages, components involved and their interactions mechanisms.
• Ask questions about configurations used in the functionality and what is the current one that is applied. Call up, problems can come because of a wrong configuration value likewise.

And so, now you have done your basis work, that'south practiced, simply then, in such a huge system involving and so many components, how to narrow downwards on the trouble expanse. At that place is this great technique for that

iv. Dissever and Conquer:

Sounds familiar!! Below steps tin help you do this effectively

• Use the collected logs to effigy out the error component. This will give an immediate reduction of solution space.
• Bank check the integration points to encounter up till where things are correct. eg: If the components are using messaging queues to interact, y'all tin can check the messages to know, how far the command flow has gone and is the problem in the producer side or in the receiver side.
• Sometimes, information technology is really hard to reproduce the issue manually. You might take to "login-> practise step1 to due north -> so error comes". In such cases, try to run across whether you can cut down the steps by writing some tests or bypass UI and brand a directly API call to the back-stop component of interest.

If you lot follow the above steps, I am sure your efforts will be spent in the correct management towards the root cause. Equally I already mentioned, there is lot more to this topic, but these guidelines volition definitely cover debugging most of the commonly occurring issues.

Oh!! wait a minute, finding the root cause is ane part of the problem, fixing it is the side by side large thing. How to exercise that efficiently?? we will sure discuss that some other time.

navadienteor.blogspot.com

Source: https://medium.com/@vignesh.littlemaster/debugging-art-or-science-5350d1bb1904

Share this post