Notes: 05. Debug a Simple Problem
The student materials have been reviewed and are updated as of SEPTEMBER 2022.
In this episode, we’ll put all we’ve learnt to find and solve a simple bug. In here, we have a basic calculator app that adds two numbers. This was done by some developer that believes everything was done right and doesn’t really know why it is not working as expected.
Currently, it displays the wrong value as the sum. Let’s try it out. If you notice, it concatenates the two numbers instead of adding them. Let’s go over to the test file and see what the expected behaviour of the app should be.
Inside the test file, we have a simple widget test. First, we check that the sum is not displayed at the start of the app. Next, we find the text fields using their keys. Then we enter “10” and “5” for the first and second text fields respectively. And notice that these values are Strings and this is simply because textfields only accepts Strings.
After that, we tap the add button. We locate it by using the find.byIcon() method and we and pass in the add icon. As you can see, the button has an add icon.
Then we call the pump() method which simulates a widget rebuild. We do this because we expect that the button press would call setState to redraw the frame with the new value. Finally, we verify that the result is displayed with the sum of the two values from the text fields.
And notice the sum is decimal based. So we expect our app to display decimal numbers.
This makes sense and if our app works like this then we would be confident that we have fulfilled this requirement. Let’s run this test and see if it passes. Click on the run action right above the test declaration. I’ll go ahead and open up the test side bar.
And you can see the test fails. And if we scroll to the top of the error message. We see that the message says that it expected to find the text with the sum value but found no widget with that text.
This shows that our app’s code doesnt fulfil the test requirement. So there is something definately wrong with our code. And this is the beauty of writing automated tests. It simply defines the expected behaviour of our widget. Then if it fails, we know something is wrong with our code.
Okay, let’s head over to the main.dart file. Then we open up the debug sidebar. First, let’s add the text from the two textfields and the sum variable to the watch list.
After that, add a breakpoint to the closing brace of the onPressed method of the button. This would break immediately after setState is called. At this point, we should have all the variables set to their expected values. Go ahead and do a hot restart.
Next, fill in the textfields and press the add button. The app breaks as expected. Let’s focus on the watch section of the debug sidebar.
Both text from the textfields are populated with their values. And notice that they are both strings. This is expected because textfields return Strings.
Next, we have the sum. And this is also a string. And that doesnt really look right. It should be a number. A decimal based number to be precise and that’s based on the test case. Let’s take a look at its definition.
And you can see that it is a string. Let’s scroll over to the the onPressed method. And we can see we are adding both texts from the text fields. This could be the reason why the developer used strings. The developer might be like: “Since the text fields return strings then the sum should be a string and dart would be smart enough to handle the computation.”
But the plus operator works differntly for strings. When used with strings, it concatenates them, hence the result we’re having as the sum. So the value of the sum is simply the concatenation of both texts. Let’s change the datatype of sum to double.
double sum;
And if we scroll to the onPressed method, we have an error. And this is simply because we need to convert those string values to type double. Let’s do that now. Update it like so:
sum = double.parse(_num1Controller.text) +
double.parse(_num2Controller.text)
Then we press the continue button to resume execution of our app. This parses those strings to double values. Save your work. And you do a hot restart simply because you’ve changed the data type. Let’s try it out.
Now it works as expected with the sum variable holding the correct value. And i’ll go ahead and hit continue. And also remove the breakpoint. Let’s check if our automated test passes this time around. Go back to the test file and run it once more.
We have a green sign which shows that the test passes and we’re confident our apps works as expected. Now, i know you might be thinking: “This bug was simple to solve.” This is definately a beginner level bug to detect but the same approach would be applied if this was a more complex scenario.
You set a breakpoint to stop the program execution at some point, then you track some variable to see if has the expected value. With this, you have a better insight of what might be causing the bug.