« Science in Politics? | Main | That which we call a subclass, by any other name... »

How Do You Test Your Code?

I've been working with Flash for a long time, and I've accrued some habits for testing and debugging as I develop in Flash. Yes, I like to work in the Flash IDE. I use trace a lot. But I also use a technique I started during my very early explorations with Flash: in project prototypes, I output to text fields on the stage during testing. I can visually lay out elements that I want to track with various user interactions that way. My teachers and professors drilled into me the impulse to constantly test my code. Write a line, test it.

Flash developers are a diverse and creative lot. How do you test and debug?

Comments

i use trace when something don't works, and the textfiled on _root to test when dealing with backend (cause seems there isn't a way to trace them)

Trace is my best friend. I did learn to properly use and abuse the debugger, and I find that helps alot when dealing with mutiple classes that have to play nice together. Backend stuff I always output to textfield and continually trace that so I have two places to check it out. I tend to shut the preview window down before I can read whats in the textfield.

I only use trace. When I need to test in a browser, I use javascript alerts instead of trace, or adding text to a debug textfield. I also have several movieclips I use on my movies only when testing.. usually FPS speedometers only, but sometimes a few additional buttons to perform some tasks faster so I can compile & test without having to navigate to some part of the movie or test on real conditions.

I use trace on every method. I use a lot of for (i in blah) trace() to look at object properties. The debugger is horrible, considering the complexity of most large apps. I've tried using it several times and it has not performed well.

We have a single Logger class that can have different listeners. It always goes directly to the trace window when inside the IDE. But the cool thing is that we can setup listeners for it like, trace windows for, screenweaver, mProjector, etc.. We also have a trace window that we built that communicates through local connection. So when we have to test within a browser we just fire open our trace window app and the traces magically appear.

I do use the as2lib's (www.as2lib.org) unit testing API for unit tests. The as2lib's speed test API for speed tests. And the as2lib's Output API that supports Logging etc. for general debugging.
If I am to lazy to do my tests and output cleanly I just use trace. ;)

I include remoting, particularly the remoting debugging this way instead of trace I use NetDebug.trace("the value = "+value);

This sends the trace to the NetConnectionDebugger so it can be tested from the IDE or from a browser.

I almost never use trace - instead, preferring the text field method. I need to get better with the built-in debuggers, but over the years have come to rely on my own debugging architecture/methods.

I use trace() predominantly for small projects and for snap debugging. For larger projects (e.g. ones involving multiple classes and such), I typically will write a quick event log component and use that instead. Never really did much use the debugger, a lot of times a quick trace is faster, and if I need much more than that, a custom logger tool typically suits my purposes better.

I have to say though, AS2 and strict typing has made debugging significantly easier by catching many of the more obvious mistakes up front prior to compiling.

Very cool. Nice to see how others go about it.

Simon, as2lib is on my list of things to check out.

Trace mostly. If I'm testing in a browser, i use this function:

function jTrace(message):Void {
getURL("javaScript:alert('" + message + "');");
}

I use trace by making a function which I can flip on and off.

//Trace Switch---------------->

tracesOn = false;
function tracer(mssg) {
if (tracesOn == true) {
trace(mssg);
}
}
//End Trace Switch---|

So I can slap _root.tracer("anything"); in my code and only have to look at the output while I'm debugging, by setting: tracesOn = true;

This just helps keep things clean for me. Also, depending on the size of your project, making several extra tracing functions might be inorder to debug different parts. (i.e. function tracerIterators(mssg);)

~jordan

I'm a fan of the built-in debugger really, i'd like to step through my code, and watch the callstack and the values of local vars, although a bug prevents me to see what really going on, i tend to use it whenever there is a ball of spaghetti code i need to debug

I use a little AS1 class which draws a basic window on screen (draggable, toggle open/close). The code's a little messy and not properly encapsulated, but it's a really easy way of debugging an appliction while it's in the browser. The class adds a global function called 'iTrace' which can be used in place of trace, and all strings get sent to the custom debugger window (and the output window when in the IDE).

You can check it out here if you're interested:
http://www.flamingmongrel.net/projects/viewProject.asp?p=16

At work I have a fancy-schmancy version I wrote which also uses a command line interface that lets me trace objects, get and set properties and call functions at runtime.