I have been using a system for testing addons that allows you to run your code outside of WoW.
This means I can use luaunit to run unit tests on the addon code and debug things without the constant edit/reloadui/look at debug in Wow cycle
There are three main parts:
1. Dump utility to save the current state (run this in game)
2. WoW Mock, using values from a dump this simulates most of the WoW API
3. Unit tests with coverage
(I used this method very successfully on PaladinAssistant/Panza and am now retro fitting it to PowerAuras)
Is this something that has already been done?
If not, and there is interest, I will package-up my stuff for general usage
See here for some examples to check-out the approach
i would also be interested myself. it sounds like something i would definately find a lot of use for. currently when testing an addon i have wow loaded in windowed mode, the addon in question in the addonsfolder and the addon lua file opened in addon studio for wow, and a macro for reloading ui lol. anything to simplify that is definately a plus in my book :)
I assure you getting a 2nd monitor (wow on one screen, code on the other) will increase productivity by more than anything else you can do. :D
Generally speaking though, I still encourage all authors to do their testing in WoW itself as nothing can really simulate WoW, particularly in these 2 areas:
1. Combat situations (especially in large raids)
2. Interactions and/or data exchange with other addons
I assure you getting a 2nd monitor (wow on one screen, code on the other) will increase productivity by more than anything else you can do. :D
Generally speaking though, I still encourage all authors to do their testing in WoW itself as nothing can really simulate WoW, particularly in these 2 areas:
1. Combat situations (especially in large raids)
2. Interactions and/or data exchange with other addons
Ofc this is not supposed to replace in-game testing completely.
1. is hard in WoW as you are raiding! Also giving users a dump method means you can have a way to recreate situations I can never get to (e.g. Ulduar raids)
2. Agreed, but that is not what I would use this for
I use test-driven development at work, and by god it's wonderful, but I have a hard time applying the concept to wow. The problem is that we are heavily dependent on wow's API for, well, basically everything... and there's jack squat in the way of tests for the API. What's the single most common cause of addons breaking? API changes.
Simulator code is great for making dry-coding a little less dry and avoiding general syntax errors... but I don't see much point in using it all as a unit testing base when the primary breaking-point of addons is something completely out of our control.
Oh and, dual screen will help a lot... so will AddonLoader. If you put AL conditions on everything you can, even simply the delayed-load, you can make reload times practically go away, it's wonderful. If your users don't have AL installed, they see no difference in how the addon loads.
I use test-driven development at work, and by god it's wonderful, but I have a hard time applying the concept to wow. The problem is that we are heavily dependent on wow's API for, well, basically everything... and there's jack squat in the way of tests for the API. What's the single most common cause of addons breaking? API changes.
Simulator code is great for making dry-coding a little less dry and avoiding general syntax errors... but I don't see much point in using it all as a unit testing base when the primary breaking-point of addons is something completely out of our control.
Well I am testing the API to a degree. For the API calls I have implemented (which are all those my addon code uses) I recorded all the outputs from the Blizzard API calls in game. If Blizzard change how the calls work then it rapidly shows me exactly what has changed (e.g. I can compare dumps before and after 3.2 drops). Equally if the arguments have changed this will quickly be apparent as the dump will fail. The big win is the dump tests all the API call at once.
The biggest thing for me is it allows me to refactor with confidence.
This means I can use luaunit to run unit tests on the addon code and debug things without the constant edit/reloadui/look at debug in Wow cycle
There are three main parts:
1. Dump utility to save the current state (run this in game)
2. WoW Mock, using values from a dump this simulates most of the WoW API
3. Unit tests with coverage
(I used this method very successfully on PaladinAssistant/Panza and am now retro fitting it to PowerAuras)
Is this something that has already been done?
If not, and there is interest, I will package-up my stuff for general usage
See here for some examples to check-out the approach
http://code.google.com/p/wowunittester/downloads/list
Sadly, most of the data i/o API is stubs, as I was mainly interested in the widget code, and this is what my simulator is very strong at.
I'm really interested in your project. What is the extent of the "state" that you save ? What API are you able to properly simulate ?
-
View User Profile
-
View Posts
-
Send Message
Forum Moderator-
View User Profile
-
View Posts
-
Send Message
Curse PremiumGenerally speaking though, I still encourage all authors to do their testing in WoW itself as nothing can really simulate WoW, particularly in these 2 areas:
1. Combat situations (especially in large raids)
2. Interactions and/or data exchange with other addons
Exactly, I can do lots of development at work with this method :)
Ofc this is not supposed to replace in-game testing completely.
1. is hard in WoW as you are raiding! Also giving users a dump method means you can have a way to recreate situations I can never get to (e.g. Ulduar raids)
2. Agreed, but that is not what I would use this for
ROFL you know it's funny... my card supports dual monitr support and i never ever thought of that :P
Simulator code is great for making dry-coding a little less dry and avoiding general syntax errors... but I don't see much point in using it all as a unit testing base when the primary breaking-point of addons is something completely out of our control.
Oh and, dual screen will help a lot... so will AddonLoader. If you put AL conditions on everything you can, even simply the delayed-load, you can make reload times practically go away, it's wonderful. If your users don't have AL installed, they see no difference in how the addon loads.
No, for me it is new features and refactoring.
Well I am testing the API to a degree. For the API calls I have implemented (which are all those my addon code uses) I recorded all the outputs from the Blizzard API calls in game. If Blizzard change how the calls work then it rapidly shows me exactly what has changed (e.g. I can compare dumps before and after 3.2 drops). Equally if the arguments have changed this will quickly be apparent as the dump will fail. The big win is the dump tests all the API call at once.
The biggest thing for me is it allows me to refactor with confidence.
See here:
http://www.wowinterface.com/downloads/info14863-UnitTestRunner.html