home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
Unit testing guidelines
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="sys" data-source="post: 31444" data-attributes="member: 17696"><p>Writing tests for existing code is a great way to help MediaPortal becoming faster and more stable.</p><p></p><p>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.</p><p></p><p>Unit Testing Guidelines:</p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>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.</p><p></p><p>[Edit]</p><p>It's consider very bad form to commit failing tests, or test that won't run on everyones computers.</p><p>[/Edit]</p><p></p><p>Read more about unit tests and TDD:</p><p></p><p><a href="http://www-128.ibm.com/developerworks/library/j-test.html" target="_blank">http://www-128.ibm.com/developerworks/library/j-test.html</a></p><p></p><p><a href="http://www.extremeprogramming.org/rules/unittests.html" target="_blank">http://www.extremeprogramming.org/rules/unittests.html</a></p><p></p><p><a href="http://www.nunit.org/" target="_blank">http://www.nunit.org/</a></p><p></p><p>_________________</p><p>[sys] - Unit Testing Guru</p><p>Cleaning Maid Deluxe</p><p>Mad Professor</p></blockquote><p></p>
[QUOTE="sys, post: 31444, member: 17696"] 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: [url]http://www-128.ibm.com/developerworks/library/j-test.html[/url] [url]http://www.extremeprogramming.org/rules/unittests.html[/url] [url]http://www.nunit.org/[/url] _________________ [sys] - Unit Testing Guru Cleaning Maid Deluxe Mad Professor [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
Unit testing guidelines
Contact us
RSS
Top
Bottom