1
0

TESTING.txt 5.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138
  1. === The Quick Guide to OpenSim Unit Testing ===
  2. == Running Tests ==
  3. On Linux:
  4. > nant test
  5. This will print out to the console the test state.
  6. On Windows: Please see the TESTING ON WINDOWS section below.
  7. Also, every checkin will run tests that are kicked off by bamboo.
  8. Results are posted here: http://www.opensimulator.org:8085/ as well as
  9. to #opensim-dev IRC channel.
  10. == Writing Tests ==
  11. Tests are written to run under NUnit. For more information on NUnit
  12. please see: http://www.nunit.org/index.php
  13. == Adding Tests ==
  14. Tests should not be added to production assemblies. They should
  15. instead be added to assemblies of the name
  16. My.Production.Assembly.Tests.dll. This lets them easily be removed
  17. from production environments that don't want the bloat.
  18. Tests should be as close to the code as possible. It is recommended
  19. that if you are writing tests they end up in a "Tests" sub-directory
  20. of the directory where the code you are testing resides.
  21. If you have added a new test assembly that hasn't existed before you
  22. must list it in both ".nant/local.include" and ".nant/bamboo.build"
  23. for it to be accessible to Linux users and to the continuous
  24. integration system.
  25. === The Gory Details ===
  26. The following is the original document which started off this
  27. document. It should probably be better integrated with the new info.
  28. ==UPDATE==
  29. The text immediately following is an update to the testing documentation. The
  30. update is written on 2008.08.30 and is copied from an email to the opensim-dev
  31. mailing list[1]. The information below the update, beginning with the section
  32. titled TESTING, is still relevant, so please read this document in its
  33. entirety.
  34. Mike Mazur
  35. [1] https://lists.berlios.de/pipermail/opensim-dev/2008-August/002695.html
  36. """
  37. The tests are contained in certain DLLs. At the time of writing, these DLLs
  38. have tests in them:
  39. OpenSim.Region.ScriptEngine.Common.Tests.dll
  40. OpenSim.Region.ScriptEngine.Shared.CodeTools.Tests.dll
  41. OpenSim.Region.ScriptEngine.Shared.Tests.dll
  42. OpenSim.Framework.Tests.dll OpenSim.Region.CoreModules.dll
  43. OpenSim.Region.Physics.OdePlugin.dll[2]
  44. The console command used to run the tests is `nunit-console` (or
  45. `nunit-console2` on some systems). This command takes a listing of DLLs to
  46. inspect for tests.
  47. Currently Bamboo's[3] build file (.nant/bamboo.build) lists only those DLLs
  48. for nunit-console to use. However it would be equally correct to simply pass
  49. in all DLLs in bin/; those without tests are just skipped.
  50. The nunit-console command generates a file TestResults.txt by default. This is
  51. an XML file containing a listing of all DLLs inspected, tests executed,
  52. successes, failures, etc. If nunit-console is passed in all DLLs in bin/, this
  53. file bloats with lots of entries like this:
  54. <test-suite name="/home/mike/source/workspace/bin/OpenSim.Grid.Communications.OGS1.dll" success="True" time="0.000" asserts="0">
  55. <results />
  56. </test-suite>
  57. <test-suite name="/home/mike/source/workspace/bin/OpenSim.Region.ClientStack.dll" success="True" time="0.000" asserts="0">
  58. <results />
  59. </test-suite>
  60. Therefore it makes more sense to me to specify the DLLs when running
  61. nunit-console.
  62. [2] Note that OpenSim.Region.Physics.OdePlugin.dll is in bin/Physics/ and
  63. needs to be first copied to bin/ before nunit-console is executed.
  64. [3] http://opensimulator.org:8085/
  65. """
  66. ==TESTING ON WINDOWS==
  67. To use nunit testing on opensim code, you have a variety of methods. The
  68. easiast methods involve using IDE capabilities to test code. Using
  69. VS2005/2008 I recommend using the testing capabilities of Resarper(commercial)
  70. or TestDriven.Net(free). Both will recognize nunit tests within your
  71. application and allow you to test them individually, or all at once, etc. You
  72. will also be able to step into debug mode into a test through these add-ins
  73. enabling a developer to jump right in and see how a specific
  74. test-case/scenerio works.
  75. Additionally, it is my understanding that sharpdevelop and monodevelop have
  76. their own nunit testing plugins within their IDE. Though I am not certain of
  77. their exact feature set or stability.
  78. == Using NUnit Directly ==
  79. The NUnit project is a very mature testing application. It can be obtained
  80. from www.nunit.org are via various package distrobutions for Linux. Please be
  81. sure to get a .Net 2.0 version of Nunit, as OpenSim makes use of .Net 2.0
  82. functionality.
  83. Nunit comes with 2 tools that will enable you to run tests from assembly
  84. inputs. Nunit-gui and nunit-console. NUnit-gui is a console that will let
  85. you view the execution of various tests within your assemblies and give visual
  86. indication of teir success or failure. This is a useful tool for those who
  87. lack IDE addins ( or lack IDEs at all ).
  88. Nunit console allows you to execute the nunit tests of assemblies via console.
  89. Its output will show test failures and successes and a summary of what
  90. happened. This is very useful for a quick overview and/or automated testing.
  91. Windows
  92. Windows version of nunit-console is by default .Net 2.0 if you downloaded the
  93. .Net 2.0 version of Nunit. Be sure to setup your PATH environment variable.
  94. Linux & OSX
  95. On these operating systems you will have to use the command "nunit-console2"
  96. Example
  97. nunit-console2 OpenSim.Framework.Tests.dll (on linux)
  98. nunit-console OpenSim.Framework.Tests.dll (on windows)
  99. For more information on testing contact the autor of this testing readme: Daedius Moskvitch ( daedius @@@@ daedius com)