ksv9x
asked on
Unit test server/client program
My project is of client/server type. The client side is using Java and the server side is using C. It uses socket to send data via packets to the clients. Clients communicating to server with the same way: using socket.
We are told to do "unit test" on each sides. For my server side, I have to test my C code. The problem is that if I don't modify the code, it will try to connect to the client therefore it is no longer a "unit test" but some kind of intergration test.
1. Hard code the "send" and "receive" packet part of the code, use printf or use debugging mode ( gdb ) to confirm "send" and "receive" data step by step.
This is very time consuming, we have to do the same thing with all the codes, and we have to remove test code after unit test is finished.
I think there must be more effective ways to do "unit test" with my case, and "unit test" in general client/server model.
Please share your opinions how to test such kind of code ( unit test ).
TIA
I am thinking of a new way to test my C code, without connecting to the client side ( so it will be independent to the Java programs ). So far, only one idea pops up in my mind:
We are told to do "unit test" on each sides. For my server side, I have to test my C code. The problem is that if I don't modify the code, it will try to connect to the client therefore it is no longer a "unit test" but some kind of intergration test.
1. Hard code the "send" and "receive" packet part of the code, use printf or use debugging mode ( gdb ) to confirm "send" and "receive" data step by step.
This is very time consuming, we have to do the same thing with all the codes, and we have to remove test code after unit test is finished.
I think there must be more effective ways to do "unit test" with my case, and "unit test" in general client/server model.
Please share your opinions how to test such kind of code ( unit test ).
TIA
I am thinking of a new way to test my C code, without connecting to the client side ( so it will be independent to the Java programs ). So far, only one idea pops up in my mind:
Hi ksv9x,
Whenever possible, I always test client/server applications by running my own version of the server on my desktop machine. If the server is host specific (like AIX, HP-UX, TRU64, etc.) there are other, often insurmountable, challenges. But even then, it's often possible to "borrow" a test system to run the server.
If it runs on a linux server, Windows Server, etc. Then it's usually pretty easy to run a copy on my local machine. The client program will be configured to connect to the desired port on the LOCALHOST (127.0.0.1).
Can you run the server program on your desktop? What about an R&D or Q/A machine?
Kent
The answer depends on what you (or whoever is requiring unit testing) consider the unit(s).
If the unit is the whole server program and you want to test the whole program without the real client program, then my colleagues' advice applies. You can write a test client program and peek into the server state to see if it is doing the right thing. Better yet, have your test program collect the server's outputs and check whether they are correct.
If the unit is something smaller, you would approach it differently. For example, you might have some application module that calls other functions to do input and output. In production, it calls functions that read from and send to a client over a network, but to test it, you could link it with test modules that supply the input from hard-coded sources rather than a network, and check what is passed to the output functions to see if it is correct. You should never need to add or remove code. You should be able to do this just by linking with different selections of modules. In order for this to work, though, your program has to be designed with multiple separate modules with different functions, not just one big module that does everything.
If the unit is the whole server program and you want to test the whole program without the real client program, then my colleagues' advice applies. You can write a test client program and peek into the server state to see if it is doing the right thing. Better yet, have your test program collect the server's outputs and check whether they are correct.
If the unit is something smaller, you would approach it differently. For example, you might have some application module that calls other functions to do input and output. In production, it calls functions that read from and send to a client over a network, but to test it, you could link it with test modules that supply the input from hard-coded sources rather than a network, and check what is passed to the output functions to see if it is correct. You should never need to add or remove code. You should be able to do this just by linking with different selections of modules. In order for this to work, though, your program has to be designed with multiple separate modules with different functions, not just one big module that does everything.
ASKER
Infinity08,
Currently I have to do the Unit Test for the server side. So far, when I am still not familiar with the system, what I did is not muture, just use printf() and observe the result printed at the console. The "messages" are string, sent by sockets.
My question is like: Can I test the server side without client one? I think I can, at some level, but having a trivial client that works and sending correct requests to server is one point, so we can use it to test the my server program.
------------------
quote from Infinity08,
Properly testing always takes time - there's no quick-and-easy solution.
To do unit testing, you indeed have to test both applications separately. Take the server side, and send it a known good message, and see what happens (the "see" part can be achieved by adding printf() statements in the code, by using a debugger, etc.).
Once the server is tested, and works correctly, you can do the same thing with the client.
I'm not sure I understand what the problem is you have with this. Can you tell me what exactly you don't understand and/or don't like ?
Currently I have to do the Unit Test for the server side. So far, when I am still not familiar with the system, what I did is not muture, just use printf() and observe the result printed at the console. The "messages" are string, sent by sockets.
My question is like: Can I test the server side without client one? I think I can, at some level, but having a trivial client that works and sending correct requests to server is one point, so we can use it to test the my server program.
------------------
quote from Infinity08,
Properly testing always takes time - there's no quick-and-easy solution.
To do unit testing, you indeed have to test both applications separately. Take the server side, and send it a known good message, and see what happens (the "see" part can be achieved by adding printf() statements in the code, by using a debugger, etc.).
Once the server is tested, and works correctly, you can do the same thing with the client.
I'm not sure I understand what the problem is you have with this. Can you tell me what exactly you don't understand and/or don't like ?
ASKER
Kdo,
The ( OS ) server is running Linux, I mean the host OS is Linux. The "server" I am using here is a special DB server ( Yes, special, developed internal used internal ). What I am am making and writing are the "modules" for the DB server. The server can't run on Windows.
So If the client - "client00" sends a "message" to the DB server in the form of a HTTP request, the DB server will call the module, says "module00", excute it and return the result to client00.
I don't think I can isolate module00 and test it without using the "client00". But one thing is that: If we use client00 ( even a trivial verison of it ) to test module00, then the test case is no longer UT, but an intergration test.
Is that right?
We had some bad exprience with the testing module: When module00 failed, we spent hours on module00 but actually client00 had bug.
I hope you can understand my problem ( sorry for my bad English and poor understanding of my system :D )
-----------------
quote from dko:
Hi ksv9x,
Whenever possible, I always test client/server applications by running my own version of the server on my desktop machine. If the server is host specific (like AIX, HP-UX, TRU64, etc.) there are other, often insurmountable, challenges. But even then, it's often possible to "borrow" a test system to run the server.
If it runs on a linux server, Windows Server, etc. Then it's usually pretty easy to run a copy on my local machine. The client program will be configured to connect to the desired port on the LOCALHOST (127.0.0.1).
Can you run the server program on your desktop? What about an R&D or Q/A machine?
Kent
The ( OS ) server is running Linux, I mean the host OS is Linux. The "server" I am using here is a special DB server ( Yes, special, developed internal used internal ). What I am am making and writing are the "modules" for the DB server. The server can't run on Windows.
So If the client - "client00" sends a "message" to the DB server in the form of a HTTP request, the DB server will call the module, says "module00", excute it and return the result to client00.
I don't think I can isolate module00 and test it without using the "client00". But one thing is that: If we use client00 ( even a trivial verison of it ) to test module00, then the test case is no longer UT, but an intergration test.
Is that right?
We had some bad exprience with the testing module: When module00 failed, we spent hours on module00 but actually client00 had bug.
I hope you can understand my problem ( sorry for my bad English and poor understanding of my system :D )
-----------------
quote from dko:
Hi ksv9x,
Whenever possible, I always test client/server applications by running my own version of the server on my desktop machine. If the server is host specific (like AIX, HP-UX, TRU64, etc.) there are other, often insurmountable, challenges. But even then, it's often possible to "borrow" a test system to run the server.
If it runs on a linux server, Windows Server, etc. Then it's usually pretty easy to run a copy on my local machine. The client program will be configured to connect to the desired port on the LOCALHOST (127.0.0.1).
Can you run the server program on your desktop? What about an R&D or Q/A machine?
Kent
ASKER
efn,
The unit is a module of the DB system ( see my previous posts for explanation ), not the whole DB server.
You have recommended a test program, hard-code it and let it send test data to the DB server. The pro of the method is that: We don't have to modify the code of the module in order to test it. But the problem is that: The test progam may have bugs! Actually, it did and we had quite amount of time with it to judge which on ( the server side and the client side ) has bugs.
Your answer is very close to me, I accept it but please reply if you have time...
Thank you
----------------------
quote from efn:
The answer depends on what you (or whoever is requiring unit testing) consider the unit(s).
If the unit is the whole server program and you want to test the whole program without the real client program, then my colleagues' advice applies. You can write a test client program and peek into the server state to see if it is doing the right thing. Better yet, have your test program collect the server's outputs and check whether they are correct.
If the unit is something smaller, you would approach it differently. For example, you might have some application module that calls other functions to do input and output. In production, it calls functions that read from and send to a client over a network, but to test it, you could link it with test modules that supply the input from hard-coded sources rather than a network, and check what is passed to the output functions to see if it is correct. You should never need to add or remove code. You should be able to do this just by linking with different selections of modules. In order for this to work, though, your program has to be designed with multiple separate modules with different functions, not just one big module that does everything.
The unit is a module of the DB system ( see my previous posts for explanation ), not the whole DB server.
You have recommended a test program, hard-code it and let it send test data to the DB server. The pro of the method is that: We don't have to modify the code of the module in order to test it. But the problem is that: The test progam may have bugs! Actually, it did and we had quite amount of time with it to judge which on ( the server side and the client side ) has bugs.
Your answer is very close to me, I accept it but please reply if you have time...
Thank you
----------------------
quote from efn:
The answer depends on what you (or whoever is requiring unit testing) consider the unit(s).
If the unit is the whole server program and you want to test the whole program without the real client program, then my colleagues' advice applies. You can write a test client program and peek into the server state to see if it is doing the right thing. Better yet, have your test program collect the server's outputs and check whether they are correct.
If the unit is something smaller, you would approach it differently. For example, you might have some application module that calls other functions to do input and output. In production, it calls functions that read from and send to a client over a network, but to test it, you could link it with test modules that supply the input from hard-coded sources rather than a network, and check what is passed to the output functions to see if it is correct. You should never need to add or remove code. You should be able to do this just by linking with different selections of modules. In order for this to work, though, your program has to be designed with multiple separate modules with different functions, not just one big module that does everything.
No matter what, your test software can be defective, and debugging the larger system of test software combined with software under test is work. It can help if the test software can show you what it is sending and receiving, so you can check its reports about whether the software under test is defective.
What about my second suggestion? Can you detach the module you want to test from the rest of the DB system and run it in isolation somehow?
What about my second suggestion? Can you detach the module you want to test from the rest of the DB system and run it in isolation somehow?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
To do unit testing, you indeed have to test both applications separately. Take the server side, and send it a known good message, and see what happens (the "see" part can be achieved by adding printf() statements in the code, by using a debugger, etc.).
Once the server is tested, and works correctly, you can do the same thing with the client.
I'm not sure I understand what the problem is you have with this. Can you tell me what exactly you don't understand and/or don't like ?