I'm trying to write tests for my chat program based on client/server interaction. After reading some sources I came up with idea of using Google Mock but the whole concept seems a little bit abstract to me. Let's say I want to test client. In order to do that, should i write a server mock that imitates the work of an actual server or I got something wrong?
Related
We´ve got the challenge to test our hardware service, it turns out to be more difficult. Mostly our hardware are RFID Reader which can perfom Mifare DESFire, Mifare Classic and Legic. We want to start easy with DESFire. The first shot was to write a complete mock reader, which understands Mifare DESFire commands but thats to much overload. Then I´m asking the community, how do you test your hardware components?
I don´t know whether a integration Test is the right way or just unit-tests, which partly mock the reader for exactly one test I´m working on. But then I never go deep down all the code till the point I can´t mock any more.
Is there a common strategy?
I am converting old C code to C++, and I am testing it as I rewrite with GoogleTest. Part of my code uses sockets to connect to a remote host, with an IPV4 address. I am having a lot of trouble understanding how I can use GoogleTest and GoogleMock to test the socket part of my code.
My object takes in a host IP address and number of seconds to wait before trying to connect to a host again. There is a function called "conn()" that actually tries to connect to the host. That is the function I want to test. So in my test, I want to do something like:
TEST(CONNECTION_TEST, Connection)
{
MyObject obj("###.###.###.###", 1);
ASSERT_TRUE(obj.conn());
}
I read on here that I needed to mock up a server since testing a remote host isn't really advisable. I am brand new to GoogleMock, so I read the official documentation and read the GoogleTest primer, GoogleMock For Dummies, the GoogleMock Cheat Sheet, and the GoogleMock Cookbook. I watched CodesBay's tutorial. I looked at several posts on SO, including What is wrong with my attempts to mock a simple C++ method with googlemock?, Patterns for unit testing a C++ method that makes a standard library call, and How to unit test BSD sockets.
For my mock server, I did the following. I made a Socket class that wraps socket.h, and then I extended MockSocket from it. In my TEST, I set up the mock socket to accept connections, like so:
TEST(CONNECTION_TEST, Connection)
{
// bind to local host?
MyObject obj("0.0.0.0", 1);
// create the host
MockSocket mock_sock;
MockSocket new_sock;
EXPECT_CALL(mock_sock, create()).Times(1);
EXPECT_CALL(mock_sock, bind(_));
EXPECT_CALL(mock_sock, listen());
EXPECT_CALL(mock_sock, accept(_));
mock_sock.create();
mock_sock.bind(123);
mock_sock.listen();
mock_sock.accept(new_sock);
ASSERT_TRUE(obj.conn());
}
As you can tell, I don't know what I am doing. My test results fail and I think it is because I just didn't do this correctly. Please, can someone guide me in the right direction? Is the mock server the correct way to test my object?
What do you want to test?
Do you want to test if the TCP/IP socket class (assuming there is one), can actually connect and communicate with some TCP/IP service? This is more an end-to-end test. You can use Google Test to do this, but you need a running TCP/IP service to communicate with. This is not where the Google mocking framework is for. This is similar to when you want to test a class that reads a file: you need to have a file that it can read and Google mocking framework will not help you here.
Do you want to test if some other class, that uses your TCP/IP socket class, works? Here you can use Google mocking framework to create a mock for your socket class. This mock will act as the socket class to your other class but will not do any TCP/IP communication. This way you can unit-test your other class.
I am looking to mock a Serial Port so I can test communication and OS flushing.
Things I am hoping for out of the mock serial port. (in order of importance to the project)
Pass istty
Able to be used with an automated test suite (no gui)
Language Agnostic
Able to run on TravisCI
Cross Platform
I don't know if all those options are possible. But doing so would be nice. I know Unix treats everything as a file, so if I could just create a file that passes istty, that would be a good solution, but probably not windows compatible.
Anyway any ideas for testing SerialPort communication would be amazing.
Thanks Everyone.
I believe if you use CMock you can pass a .h file and get a mock generated.
Failing that, I'd write one by hand. Nothing fancy, just the stubs and some basic known return values. Once the mock (and your tests/unit under test) is sufficiently developed, that's when I'd switch to an integration test with the real socket API
I'm currently working on transitioning a small console application to a TCP server / client application. The client will connect to the server via any Telnet client, and the server will replicate the standard console interface for each Telnet connection.
I started looking into doing this using the techniques I've learned from Beej's guide to network programming -- accepting the connection and then using fork() to separate it into its own process.
However, I would prefer to maintain my use of streaming IO (the original console application uses cin / cout, using similar functions for the networking logic would make the conversion process much simpler).
I've discovered the TCPStream class, hiding within sockets.h (http://www.gnutelephony.org/doxy/bayonne2/a00215.html)
It appears this class will allow me to use the server with streaming IO. However, I can't find a single example of using this class, nor can I find an explanation as to how to use fork() with it.
Any ideas? Thanks in advance for any help.
I think you are confusing the trees for the forest. One socket class is such a small part of what you need to do overall that it is not worth focusing on that.
If your objective is just to get your project working then just use an existing framework rather than trying to pull individual classes out of a large project. POCO has a TCPServer class that will do 90% of the work for you. QT, ACE and others have similar classes. There is not a huge amount of documentation on POCO but they do cover TCPServer pretty well and you can learn a lot from reading the source code if that is really where your interest lies.
we have one main application, which executes up to 5 different exes. These exes run independently and communicate with each other via UDP. Changing this architecture is not planned at the moment.
We want to migrate this whole thing from VS6 to VS2008.
I'm thinking about adding unit tests to make sure that after migration everything still works. Right now, there is not a single unit test.
So now I have a couple of questions:
Which unit test framework works fine with VS6 and VS2008? CppUnit seems to work with both compilers, at least I got it running.
How do I implement the unit tests in the above mentioned architecture? I see a problem that I have executables and no libraries, so it seems to be a bit difficult for me at that point
Is creating the unit tests for both platforms worth the effort or do you have a simpler suggestion?
Suggestions, best practices, new ideas welcome :)
Thanks
If they communicate via UDP and you want to make sure the integration between pieces works now and later, you could write automated tests against the UDP interfaces in MSTest or NUnit in VS2008.
Write the tests in VS2008 and send input/verify output of the interfaces to the the .exe applications. Then, when you switch to .NET, just point your tests at the new endpoint for the .NET .exe and run them to verify all input and output are the same.
I think you would get more bang for your time to write the unit tests exclusively for the new app, but write tests against the external UDP interfaces to verify the migration was successful.
If you are willing to consider each of the executables as as 'module', then there is a way to introduce tests without being too invasive.
This would create modules that will be a bit large for many people to be comfortable with (typical sizes when people talk about modules is a class or a source file), but your communication mechanism provides a nice way to hook in the tests.
With the architecture that you have and the fact that you don't have an existing test harness for the code, I would write a test harness that can communicate with each of the executables in isolation, using the UDP interfaces.
When executing the tests, only one executable is running (besides the test code). The test code simulates the other executables by listening on their respective UDP ports and providing responses as the testcase requires. The testcase also stimulates the executable under test by sending UDP requests to it. If there is also a GUI/TUI involved, it might be needed that parts of the tests are executed manually.