Writing tests for existing code is a great way to help MediaPortal becoming faster and more stable.
Another way is to expose bugs by writing a test or two that fail as long as the bug is in place. If you don't feel comfortable with fixing the code, write a test for it, and you are helping the devs.
Unit Testing Guidelines:
Tests should be kept very small! Your tests should be around 10 lines long - no more. If you can't write tests smaller, you should look at your code and see if you could split it up better. But it's always better with a test than with no test at all.
Write tests that are readable! Use good variable names, and avoid long lines. If you have to comment your tests you are definatly writing them wrong - the test code should be self-explanatory.
Don't create tests that depend on each other. If your tests are only green if you run them in a certain sequence, you are doing it wrong.
Check boundary conditions heavily. If the parameter of a method expects values in a specific range, your tests should pass in values that lie across that range. For example, if an integer parameter can have values between 0 and 100 inclusive, three variants of your test might pass in the values 0, 50, and 100 respectively.
Use negative tests to be sure your code responds to error conditions appropriately. Verify that your code behaves appropriately when it receives invalid or unexpected input values. Verify that it returns errors or throws exceptions when it should. You might be surprised to find that a test you expected to fail actually succeeds. For example, if an integer parameter to a method can accept values in the range 0 to 100 inclusive, you might create tests that pass in the values -1 and 101.
[Edit]
It's consider very bad form to commit failing tests, or test that won't run on everyones computers.
[/Edit]
Read more about unit tests and TDD:
http://www-128.ibm.com/developerworks/library/j-test.html
http://www.extremeprogramming.org/rules/unittests.html
http://www.nunit.org/
_________________
[sys] - Unit Testing Guru
Cleaning Maid Deluxe
Mad Professor
Another way is to expose bugs by writing a test or two that fail as long as the bug is in place. If you don't feel comfortable with fixing the code, write a test for it, and you are helping the devs.
Unit Testing Guidelines:
Tests should be kept very small! Your tests should be around 10 lines long - no more. If you can't write tests smaller, you should look at your code and see if you could split it up better. But it's always better with a test than with no test at all.
Write tests that are readable! Use good variable names, and avoid long lines. If you have to comment your tests you are definatly writing them wrong - the test code should be self-explanatory.
Don't create tests that depend on each other. If your tests are only green if you run them in a certain sequence, you are doing it wrong.
Check boundary conditions heavily. If the parameter of a method expects values in a specific range, your tests should pass in values that lie across that range. For example, if an integer parameter can have values between 0 and 100 inclusive, three variants of your test might pass in the values 0, 50, and 100 respectively.
Use negative tests to be sure your code responds to error conditions appropriately. Verify that your code behaves appropriately when it receives invalid or unexpected input values. Verify that it returns errors or throws exceptions when it should. You might be surprised to find that a test you expected to fail actually succeeds. For example, if an integer parameter to a method can accept values in the range 0 to 100 inclusive, you might create tests that pass in the values -1 and 101.
[Edit]
It's consider very bad form to commit failing tests, or test that won't run on everyones computers.
[/Edit]
Read more about unit tests and TDD:
http://www-128.ibm.com/developerworks/library/j-test.html
http://www.extremeprogramming.org/rules/unittests.html
http://www.nunit.org/
_________________
[sys] - Unit Testing Guru
Cleaning Maid Deluxe
Mad Professor