Extreme Programming

[joevenzon]

http://www.extremeprogramming.org/

"Extreme programming" is a pretty lame name, but I like a lot of their concepts. Writing "unit tests" before developing the code (an then using it as an automated regression test before releases) is handy in many ways, including making the code's purpose easier to understand. Their release planning, using "user stories", and acceptance tests, sounds like a cool way to do things, too.

[thelusiv]

I always thought that calling it extreme programming is a little goofy, it's just software engineering. I took a class on all these concepts. I agree we should try doing it. It's a great way to control the chances for errors and make sure individual parts work.

Here are some ideas we can employ in game development to better test our work:

• on a class-by-class basis, develop stress tests that flex the different features of each class
  
• test not only for errors but performance factors
  
• set up a testing suite that performs tests on all the components and generates a report
  
• perform regular tests on multiple platforms, and track reported results
  
• besides automated tests, human testing needs to be done on more "fuzzy" criterion, and reported in a uniform way

In order to get consistent information from user testing, I think we need to improve our documentation, and find a way to get users to give us more information. One possible way would be to use a bug tracker, thus they have a form they have to fill out, giving us plenty of info. Another way would be to develop better documentation telling people the information we need because all too commonly, we don't get enough. Personally I think a well set-up web bug tracker would really be the best solution, but that means the developers have to commit to using it. That probably means closing the bugs forum on the site and directing people to always go to the bug tracker site, and that sort of thing.

Anyway a bug tracker isn't directly necessary for good user testing, or good software engineering. It's just one tool that can be used towards that end.


I'd say as we work on things for the upcoming release we should develop some unit tests, and improve our documentation as much as possible. Not only the docs on the wiki, but we should also document our code better (right now it could be said that we do it "not at all" ), at least descriptions for what different functions and classes do.

[joevenzon]

One of the things I like about unit testing is that it is an additional way of showing what a function is supposed to do.

Anyway, I think the place to start would be adding unit tests for new functionality and starting to develop some "user stories."

[thelusiv]

The term I've heard a lot for "user stories" is use cases. The idea, for those not familiar, is to collect a list of all the possible ways a user might want to use the program, and the constraints placed on the usage, etc. This provides a concrete set of tests which can be verified and run to establish how well the program is working.

For us it'd probably be a good idea to divide our use cases up into categories, since we have several different modes in which the game is used. For instance, we could have categories for menus, practice games, single races, career mode, replays, network games, etc.

[joevenzon]

thelusiv, have you looked at http://trac.edgewall.org/? It seems like a pretty good, simple issue tracking system.

[thelusiv]

Trac looks nice. I'll set up a test site after the release and we can play around with it...