Running the Bluetooth Test
The Bluetooth Test executes the unedited command line tux –o –d btw22 on default execution. This command-line entry skips all server-related and connection-related test cases. In order to run the Bluetooth Test with a server, the client and the server must be able to communicate using TCP/IP. You must also edit the command line to allow the client to pass the host name or IP address of the server to the test .dll file. The following procedure shows the steps you must take to run the Bluetooth Test with a server.
To run the Bluetooth Test with a server
Copy the Btwsvr22.exe file and the Netall.dll file to the release directory or to the Windows directory on the server.
You can find the Btwsvr22.exe file and the Netall.dll file in the Cepb\Wcetk\Ddtk\%_TGTCPU% directory in the directory where you installed Platform Builder.
On the server, run the Btwsvr22.exe file.
If the server cannot find or cannot load the Netall.dll file, the server displays an error message stating that Btwsvr22.exe is an unknown command. If you see this error message, verify that you copied the Netall.dll file to the correct location.
In the Windows CE .NET Test Kit window, right-click on the Bluetooth test, and then choose Edit Command Line.
Modify the command line so as to pass to the test the host name or IP address of the device running Btwsvr22.exe.
For example, if the device running Btwsvr22.exe has a host name of Cetest1 and an IP address of 4.3.2.1, type -c "cetest1" or -c "4.3.2.1" at the end of the existing
tux -o -d btw22command line.From the Windows CE .NET Test Kit window, start the Bluetooth test.
The following table shows the various test cases for the Bluetooth Test.
| Test Case | Description |
|---|---|
| 101 | Opens a Bluetooth socket and then closes the socket. This test case fails if a call to the socket or closesocket functions fails on the Bluetooth address family. |
| 102 | Binds a Bluetooth socket to a valid address. This test case fails if the bind function call fails. |
| 103 | Binds a Bluetooth socket to a valid address. The test case then attempts to bind the same socket to the same address to verify that a second attempt to bind fails. This test case fails if the second bind function call succeeds. |
| 104 | Executes a call to the listen function with a backlog value set to 0. This test case fails if the listen function call fails. |
| 105 | Executes a call to the listen function with a backlog value set to 1. This test case fails if the listen function call fails. |
| 106 | Executes a call to the listen function with a backlog value set to 5. This test case fails if the listen function call fails. |
| 107 | Executes a call to the listen function with a backlog value set to 8. This test case fails if the listen function call fails. |
| 108 | Executes a call to the listen function with a backlog value set to SOMAXCONN. This test case fails if the listen function call fails. |
| 109 | Executes a call to the listen function with a backlog value set to SOMAXCONN+1. This test case fails if the listen function call fails. |
| 110 (This test only runs if you run the server tests) | Creates a Bluetooth connection from the client to the server. This test case fails if the connection fails. |
| 112 (This test only runs if you run the server tests) | Creates a Bluetooth connection from the server to the client. This test case fails if the connection fails. |
| 113 (This test only runs if you run the server tests) | Creates a Bluetooth connection from the client to the server, terminates the connection, and then establishes a new connection to the same port on the server. This test case fails if one of the two connections fails. |
| 114 (This test only runs if you run the server tests) | Creates two Bluetooth connections on different ports simultaneously. This test case fails if the two connections cannot exist simultaneously. |
| 115 (This test only runs if you run the server tests) | Creates two Bluetooth connections from client to server simultaneously. The client closes the first connection immediately after the connection is established. The server then closes the second connection. This test fails if the two connections cannot be made or if they fail to close in the specified order. |
| 116 (This test only runs if you run the server tests) | Transfers 10 bytes of data from the client to the server by sending 1 byte of data at a time. This test case fails if the data transfer fails. |
| 117 (This test only runs if you run the server tests) | Transfers 100 bytes of data from the client to the server by sending 10 bytes of data at a time. This test case fails if the data transfer fails. |
| 118 (This test only runs if you run the server tests) | Transfers 1000 bytes of data from the client to the server by sending 100 bytes of data at a time. This test case fails if the data transfer fails. |
| 119 (This test only runs if you run the server tests) | Transfers 10000 bytes of data from the client to the server by sending 1000 bytes of data at a time. This test case fails if the data transfer fails. |
| 124 (This test only runs if you run the server tests) | Attempts to transfer 0 bytes of data from the client to the server. This test case fails if the data transfer fails. |
| 125 (This test only runs if you run the server tests) | Attempts to send and receive data simultaneously. This test case fails if the data transfer fails. |
| 126 (This test only runs if you run the server tests) | Creates a connection, transfers data, and then shuts down the connection with the value of the how parameter of the shutdown function set to SD_RECEIVE. The test case then attempts to receive data on the same socket. The recv function call is expected to fail. This test case fails if the recv function call succeeds. |
| 127 (This test only runs if you run the server tests) | Creates a connection, transfers data, and then shuts down the connection with the value of the how parameter of the shutdown function set to SD_SEND. The test case then attempts to send data on the same socket. The send function call is expected to fail. This test case fails if the send function call succeeds. |
| 128 (This test only runs if you run the server tests) | Creates a connection, transfers data, and then shuts down the connection with the value of the how parameter of the shutdown function set to SD_BOTH. The test case then attempts to send and receive on the same socket. The send and recv function calls are expected to fail. This test case fails if the send or recv calls succeed. |
| 201 | Tests the socket function call with various legal and illegal parameters. This test case fails if the socket function call fails in the legal cases or succeeds in the illegal cases. |
| 202 | Tests the WSASocket function call with various legal and illegal parameters. This test case fails if the WSASocket function call fails in legal cases or succeeds in illegal cases. |
| 203 | Tests the bind function call with various legal and illegal parameters. This test case fails if the bind function call fails in legal cases or succeeds in illegal cases. |
| 301 (This test only runs if you run the server tests) | Creates a listen function call with the backlog value set to 0 and then connects. This test case fails if the listen function call fails or the connection fails. |
| 302 (This test only runs if you run the server tests) | Creates a listen function call with the backlog value set to SOMAXCONN and then connects. This test case fails if the listen function call fails or the connection fails. |
| 303 (This test only runs if you run the server tests) | Creates a listen function call with the backlog value set to 8 and then connects. This test case fails if the listen function call fails or the connection fails. |
| 304 (This test only runs if you run the server tests) | Creates a listen function call with the backlog value set to SOMAXCONN+1 and then connects. This test case fails if the listen function call fails or the connection fails. |
| 305 (This test only runs if you run the server tests) | Tests the getpeername function. This test case fails if the getpeername function call fails. |
| 306 (This test only runs if you run the server tests) | Tests the getsockname function. This test case fails if the getsockname function call fails. |
| 309 | Tests the SO_ACCEPTCONN option of the getsockopt function on a listening socket. This test case fails if the getsockopt function call fails. |
| 310 | Tests the SO_ACCEPTCONN option of the getsockopt function on a socket that is not listening. This test case fails if the getsockopt function call fails. |
| 311 | Tests the SO_TYPE option of the getsockopt function. This test case fails if the getsockname function call fails. |
| 312 (This test only runs if you run the server tests) | Tests the SO_LINGER option of the getsockopt function. This test case fails if the getsockname function call fails. |
| 313 (This test only runs if you run the server tests) | Tests the SO_LINGER option of the setsockopt function. This test case fails if the setsockname function call fails. |
| 402 | Attempts to enumerate any SD service record with L2CAP_PROTOCOL on the local device. This test case fails if no SD service record is found on the local device. |
| 403 (This test only runs if you run the server tests) | Attempts to enumerate any SD service record with L2CAP_PROTOCOL on the remote device. This test case fails if no SD service record is found on the remote device. |
| 404 | Registers a new SD service record and then attempts to enumerate the server locally. This test case fails if a newly added SD service record is not found on the local device. |
| 405 | Attempts to modify an existing SD service record. This test case fails if it is not possible to modify the existing SD service record. |
| 406 | Attempts to delete an existing SD service record. This test case fails if it is not possible to delete the SD service record. |
| 407 (This test only runs if you run the server tests) | The server registers a new SD service record and the client queries the newly registered record. This test case fails if the client does not find an SD service record. |
| 408 (This test only runs if you run the server tests) | Tests the service attribute search. This test case fails if the service attribute search fails. |
| 409 | Attempts to register a new service record with the SERVICE_MULTIPLE flag. The attempt to create a new service record is expected to fail. This test case fails if a new service record is created. |
| 410 | Attempts to register an invalid SD service record. This test case fails if a new service record is created. |
| 411 | Attempts to update an existing SD service record with an invalid one. This test case fails if the service record is updated. |
| 412 | Attempts to delete an existing SD service record that does not exist. This test case fails if no error is returned. |
| 413 | Attempts to delete an existing SD record two times. This test case fails if the first delete fails or the second delete succeeds. |
| 414 | Attempts to look up an SD service record using the lpServiceClassId parameter instead of the lpBlob parameter. This test case fails if the attempt to look up the service record fails. |
| 415 | Attempts to look up an SD service record on a device that does not exist. This test case fails if the attempt to look up the device succeeds. |
Remarks
This test library can have one or more optional command line entries to change the behavior of the test. To specify one or more optional command line entries to the test library, you must use the –c command line option. This option forces Tux to pass the specified string into the test library.
See Also
Last updated on Friday, October 08, 2004
© 1992-2003 Microsoft Corporation. All rights reserved.