So, your in the process of making an app, not just any app, but the most electrifying app that has ever been known to mankind. Before shipping your app, there are a few things you have check on. Is your app intuitive? Does it make sense placing a button on the main page when a swipe gesture could be better? How pretty is your app? We all know apps that look pretty sell well, for instance, take a look at the iPhone Hippies (hipsters and hippies who go ooh and awe for anything that Apple makes). How secure is your app? Is it NSA proof? Apps dealing with sensitive data needs to be handled accordingly, and by that, I don’t mean by the NSA. Does your app fit the requirements of its demographics? Think of who would be using your app and make all needed features to accommodate that user and keep them happy. A few other things to keep in mind would be the speed of the app (is there a need for speed?), its localization (location based services), internationalization (the more places your app resides the more money you make – North America, South America, Europe and so on), lastly how stable is your app? You won’t know how stable it is unless you test the hell out of it.
What are your options in testing your app then? There are a couple ways of going about this. One is using Unit Testing and another would be integration testing. The most common form of testing is integration testing. If your a developer more than likely you already have done integration testing.
Integration testing in a nut shell are tests that are not fast nor consistent and heavily depend on other units of the system in order to retrieve an end result. Its all integrated. One part does not work without the help of another. You can think of a car engine as a type of integration. It relies heavily on subsystem after subsystem in order to get it to work. Parts relying on other parts to produce an end result. The car moving would be that end result. Realistically, you would want to perform both types of testing (unit testing and integration testing). Its a lot of work, but the end result is worth it. This post will lead to many other debugging posts using Visual Studio’s debugger and later on to unit testing.
So for starters, let us discuss what a breakpoint and tracepoint is. A brief introduction of both is that a breakpoint tells the debugger, “Hey man, you might want to check this out, line 231. It looks fishy.” When the debugger acknowledges the breakpoint it pauses execution. At that point you can view all local variables in that method, the stack trace, outputs and do some inspection at that point of execution. This pause that the breakpoint initiates is called the break mode.
Tracepoints is the new kid on the block. A tracepoint is a breakpoint, but with hipper clothes and a swagging haircut. The tracepoint sort of looks like Vanilla Ice – To the Extreme, but much more level headed. The tracepoint lets you associate custom actions to the breakpoint. It tells the breakpoint “Alright stop! Collaborate and listen, Ice is back with his brand new invention…”. And all the other breakpoints are like “Ice Ice Baby, too cold, too cold…”. When a tracepoint is hit, the debugger performs whatever action(s) the tracepoint defined, including breaking program execution. I use tracepoints to print out messages of variables to the Output window as execution happens. There are times where I just get tired of stepping through code so I let the tracepoint do the work. Here’s an example of what setting up a tracepoint looks like. You would want to right click, in the source code, where you want to set the tracepoint at, select Breakpoint->Insert Tracepoint.
In future posts I’ll discuss what types of breakpoints/tracepoints there are. This is just serving as a little primer/introduction to both. Till next time.