1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/os/ossrv/genericopenlibs/cstdlib/TSTLIB/TNETDB/ReadMe.txt	Fri Jun 15 03:10:57 2012 +0200
     1.3 @@ -0,0 +1,43 @@
     1.4 +How To Run TNETDB test case manually (Windows Environment)
     1.5 +
     1.6 +(1) One has to replace epoc.ini (this epoc.ini was provided by Networking team) file which has WIN_TUNNEL field. 
     1.7 +This field has networking test network IP address and port number.
     1.8 +
     1.9 +(2) One has to build //PR/share/DABSRelease/buildtools/wintunnel/eka2/wins/... component.
    1.10 +So that wintunnel application will redirect the HostResolver request to Networking Test Network.
    1.11 +
    1.12 +How To Run TNETDB test case manually (Hardware)
    1.13 +
    1.14 +(1) Include StdLibTests.iby at the time of building ROM.
    1.15 +(2) Start TCP2SER application in the PC to which H2/H4 hardware is connected.
    1.16 +Please refer to (http://loncoredev01.intra/twiki/bin/view/ToolsAndUtilities/TCP2SerTool) link for further detail.
    1.17 +(3) In the hardware, go to z:\test directory and run TNETDB. Before running TNETDB, TCP2SER must be started as that
    1.18 +application will be responsible for re-directing the request to Test Network.
    1.19 +
    1.20 +NOTE: The above epoc.ini (which has WINTUNNEL info) and wintunnel application are needed at the time of testing in Emulator but not in hardware.
    1.21 +At the time of testing in hardware TCP2SER will be used in place of wintunnel. 
    1.22 +
    1.23 +Why use Networking Test Environment ?
    1.24 +
    1.25 +GetHostByName and GetHostByAddr uses RHostResolver class which internally sends the request to internet to get the info.
    1.26 +But networking team is using their own test environment to simulate above things. As we are calling their functions to
    1.27 +do our stuff we need their environment too.
    1.28 +
    1.29 +GetHostByName and GetHostByAddr might return multiple host names for a single address or
    1.30 +multiple addresses for a single host name. All these Host reolve info was stored in their 
    1.31 +test environment. So it is easy to test and compare the test result as the addresses were not changed.
    1.32 +
    1.33 +Few Reasons TNETDB might fail.
    1.34 +
    1.35 +(1) In the test code, addresses and host names are hard-coded. So check wheter the test is failing
    1.36 +at the the time of comparing the results. It might be due to change of addresses and host names in test database.
    1.37 +
    1.38 +If you are testing in Emulator:
    1.39 +
    1.40 +(2) As epoc.ini was copied once from networking team. Cross check whether epoc.ini file is still relevant or not.
    1.41 +Or Networking team has changed their testing strategy. (As this test case is closely associated with networking test environment).
    1.42 +
    1.43 +If you are testing in Hardware:
    1.44 +
    1.45 +(2) Check whether you have correct config.xml file in TCP2SER directory. For detail please refer to
    1.46 +http://loncoredev01.intra/twiki/bin/view/ToolsAndUtilities/TCP2SerTool