Auxiliary class -- unit test in xNa

Unit Test in xNa

This section briefly discusses unit testing before the project to be introduced in this book goes further into the details of the helper class. In the previous chapter, you have learned static unit test ). Static unit tests are ideal for Fast Detection of Visual Results, testing of physical features and controllers, and quick game building. However, helper classes and components do not require user input, but you need to consider their interfaces. This is meaningless, because unit testing is primarily intended to improve your applications.ProgramAnd make sure that everything is running as error-free as possible. For example, you can call the followingCodeTo test whether the log class works:

 
Filehelper. deletefile (log. logfilename); log. Write ("New log entry ");
 

Tip:

This code can only be executed within the log class, because log. logfilename is private.

Now, you can go to the application folder to check whether a log file exists, and there is an entry with the word "New log entry" in it. However, it is a bit difficult to check the content of this file. Instead of recording every error message here, you should only place the unimportant warning information (for example, the user is not connected to the Internet) to the log, an exception is thrown when a fatal error occurs (for example, texture cannot be found or shader is unavailable ). This is especially true when problems increase, testing becomes more complex, and involved in a long detection process. By making unit test self-detection, you can avoid self-checking errors and make them automatically executed, instead of calling them in the program class as you would using static unit tests.

Nunit and testdriven. net

To do this, you can use the popular nunit framework. You can download the license at http://www.nunit.org.

You can also use testdrive.netfrom http://www.testdriven.net/to use Visual Studio 2005 Professional or higher. It supports many very cool features. You can use hotkeys or pop-up menus to start testing. This is really cool and simple. Testdriven. net cannot work in VC # express or xNa studio Express (it worked a year ago, but developers had to delete this plug-in that supports Express, this is because Microsoft wants developers to use professional edition in large programs ). For details about how to make xNa work in Visual Studio 2005, see Chapter 1. You can use a virtual project in xNa studio express to process content clips, which is not possible in Visual Studio 2005.

No matter which version you install, you only need to set nunit from the installation folder. framework. DLL is added to your project (right-click your project and add a new reference; If nunit is not found in global assembly cache. framework. DLL, you can use "Browse", which is the first tab to be rendered .). Now you can add the following using command:

 
# If debugusing nunit. Framework; # endif
 

I usually add this code at the top of the using command area. It is only used in debug mode because unit testing is used only for compiling in debug mode; you do not want this additional nunit for the final game. framework. DLL and all the test code, because your game does not need it.

Take a look at the first unit test used in the stringhelper class. This class checks whether the isinlist auxiliary method works as expected:

[Testfixture] public class stringhelpertests {// <summary> /// test isinlist /// </Summary> [test] public void testisinlist () {assert. istrue (isinlist ("whats", new string [] {"hi", "whats", "Up? "}, False); Assert. isfalse (isinlist (" no way ", new string [] {" OMG "," No no "," There is no way! "}, False);} // testisinlist ()...
 

Assert is a helper class in the nunit framework. It contains methods to check whether the returned values meet expectations. If the returned value is not as expected, an exception is thrown. You can immediately see the row where your test failed. For example, assert. istrue checks whether the return value of the isinlist method is true. If the returned value is false, an exception is thrown. Fortunately, the string array contains "whats". This test should pass. The next test checks "no way", and the string is not in the second string array. Therefore, the second test line should return false according to the rule. Note: "There is no way !" The "no way" method is included, but you are not testing the contains method here, although this method also exists in the stringhelper class. If the exact string is found in the list, the isinlist method returns true.

Start Unit Test

Right-click and select "Run test" (3-6.. net. If you do not have or cannot use testdriven. net, you can also use the nunit program. You can also use testdriven. Net to perform static unit tests in the same way, but nunit GUI does not support static unit tests. Therefore, I added unit tests to program. CS (or the unittesting. CS class in the following project) to support all users and xNa studio Express. Testdriven. net can be used to start dynamic and static unit tests. However, to work properly after version 2.0, you must delete the [test] feature from the static unit test (in short, none of the static unit tests in this book can use the [test] feature ).

Figure 3-6

The test will run without any errors. However, if you change the test and change "whats" to "whats up", the first assert test will fail and you will see that it is from testdriven. net:

Testcase'm: xnabreakout. helpers. stringhelper. stringhelpertests. testisinlist 'failed': nunit. framework. assertionexception at nunit. framework. assert. doassert (iasserter asserter) at nunit. framework. assert. istrue (Boolean condition, string message, object [] ARGs) at nunit. framework. assert. istrue (Boolean condition) c: \ code \ xnaracer \ helpers \ stringhelper. CS (1387,0): At xnabreakout. helpers. stringhelper. stringhelpertests. testisinlist () 0 passed, 1 failed, 0 skipped, took seconds.
 

It will tell you the exact location (you can even double-click the error message to jump to row 1387) and what to modify. If nunit is used, the error is even more intuitive (3-7 ):

Figure 3-7

Nunit GUI is a good tool for running multiple unit tests at a time, and it quickly shows which one does not work normally, and then goes deepSource codeResearch. You can select your program by using the menu bar, and drag and drop the .exe or. dll file of any.netto the nunit GUI program. Then we can see all the unit tests in assembly, and click "run" to test. The program is good, but I usually do not want to switch out of the development environment during coding or testing, so I prefer testdriven. NET and keep using it. To fix this error, you only need to change the "whats up" line back to "whats", so that all tests will pass and you will receive a green light.

Golden Law

Here I am not prepared to go too deep into unit testing, because the basic rules have been discussed in Chapter 2 and they also apply to dynamic unit testing. Keep these guidelines when writing your first unit test:

• Think about your problems and break them down into a small part that is easy to manage.

• Write the test first. do not consider the specific implementation, the final code that you think should be, or the game code that you want to look like.

• Try to make sure that there are as many tests as possible. For example, testisinlist not only tests the successful call to the isinlist method, but also tests the failed call to it. Unit Tests take some time, but do not exceed 50%-you do not need to write 30 tests for methods with only two lines of code.

• The test starts from this moment without interruption, even if you think it doesn't make much sense. This forces you to see what to do and how far away from the implementation process. At the beginning, the test cannot even be compiled because you have not implemented anything. After some empty methods are executed, the test will fail because you have not done anything. Finally, when everything works properly, you will feel much better.

• Even if you do not perform static unit tests very frequently, dynamic unit tests are executed every time you compile the code (if they all run fast enough ). Always try to run all unit tests once a day or once a week to ensure that your latest code changes do not add new errors.