FreeGameDev

I've noticed in a lot of areas of life, there are are whole bunch of unwritten rules and things are done a certain way, but no one ever bothers to write them down. Then someone just breaking into the community has a hard time because they never know what they did wrong.

Well, recently I decided I might like to try to contribute to another free software project. The latest version of distributions (fedora core 16, 64 bit) break my old athena widget based wograld map editor, so I thought perhaps I would try to change gridarta in order to add support for wograld maps. Then I found out that gridarta doesn't just support crossfire, but a couple forks, Daimonin and Atrinik as well. Anyway, the lead developer for gridarta looked at our code and did not like it. He said all the unit tests were broke. When I forked crossfire to make wograld, I did not know what a unit test was or what they were for. He also did not like the fact we were still using CVS.

Okay, now I have several questions.
1 What is a unit test and do most projects insist on them?
2) How can I retroactively write unit tests for the current wograld project?
3) Why do people care so much about switching to subversion?

i think I can answer #3.
SVN(subversion) is where all the files are stored in a way so anyone from anywhere with an Internet access can get them/commit to it. people like that so that is why they use it.

Those are not really unwritten

Unit tests are tests that a programmer writes and that are automated to execute and provide reports on their success or failure. The tests allow a programmer to see if a change he made caused some side effect where another piece of code failed. It's part of a programming methodology and, though you may not fully comply with test driven programming, having unit tests will ease development. Please keep in mind that writing tests does take time and that a test need to be well written in order to be useful.

Please take some time to properly research what unit tests are and what they can offer, also what are the downsides of them. You can start with http://en.wikipedia.org/wiki/Unit_testing

You need some sort of testing framework, and then you need to write the tests using that framework's features. Unit tests are just small functions written in the same programming language as your project. If you already have unit tests and they are broken you need to update them so that the code tests your changes, just open the test files and start programming the tests

CVS was something good when there was nothing else available (I actually don't think it was ever good ), now with SVN, Git, Mercurial and so many other version control systems it's a good idea to change to a more recent software, one that helps integrate patches and new contributions.

I don't know about the project you are talking about, but if I used Subversion and you provided me with a patch using CVS I would probably reject it also since the differences would easily cause problems in integrating you code, unless the contribution was really simple, integrating code can be a nightmare and one I always try to avoid. I was a SVN user for about 4 years and then changed to Git just because it is so much easier to merge code and fork projects.

Don't get me wrong, every software has it's problems, and Git is no exception, but for the usual taks of accepting outside contributions it has been one of the best I could find. So I'm guessing the lead developer just doesn't want to handle all the problems that could arise from trying to use your patches against his repository.

Unit tests, if done properly, greatly decrease the chance of development introducing issues into code that previously worked.

Consider:

{l Code}: {l Select All Code}

fun A(a, b) { return a + b; }
fun B(a, b, c) { return A(A(a, b), c); }

(Appreciate this is totally arbitrary, so ignore the purpose of the functions.)

Say a developer desires the behaviour of A to be different, and doesn't pay attention to its usage in B. He changes A to be a*b and this means B now behaves differently.

If there was a unit test on B, this unit test would fail and the developer would be forced to pay attention to B.

Unwritten rules of open source development?

• Release early, release often. This serves as a showcase and visible measurement of activity.
• Be available and accessible. This basically means that people have some means to talk to you, the more public the better. Otherwise you won't get any new devs, as those are bound to have questions once they become interested in your project.
• Have a homepage to show your project to the world and maintain it.
• Make sure they can access your code repository (write access is not a necessity, though). This allows people to develop patches and gives them an idea of what you are doing.

@xahodo these are the unwritten rules of open source marketing, which is a subset. I agree with these rules too