I am working on introducing tests to an old system. Because of the amound of technical debt, we have landed on component/interface testing.

The system is a servies of servers which sends messages in a custom format between each other. The idea is to create a framework where we can create a testcase to stimulate a server, then mock the messages that it sends to others servers and finally validating the respons on the original request.

My question, what is the best design for this? Due to restrictions, a little as possible code should be changes. I see two different approches. In process and out of process test framework

In process: Store testcases and test framework in a dll which is dynamically loaded by the server we want to test. A NetworkObserver needs to be created, which can forward information to the TestFramework enter image description here

Out of process: Create a new servers which listens to what the server we want to test does. The test server needs to have first priority for handling messages so it can potentially mock request. enter image description here

The design drawings are not amazing, but hopefully they make it easier to understand.

Things to consider:

  • The servers are multithreaded

  • There is a lot of db access

  • I would like to run the same test cases in two modes. One for validating the internal and one where I validate the mock data against the actuall data returned by the other servcies. For this to work I need to set some spesific data on some of the servers which communicate with external systems.
  • There are a lot of config files.

I would love some input on how to best handle this. Is there a 3rd way of doing this?

  • Removed that part. Is this not a good place to ask for feedback on ideas and problems? – user1038502 Jun 28 '18 at 16:32
  • Why bother to mock? If you record and replay actual messages, it is not called mocking. Actual mocking, where you try to reproduce messages via code, is probably a waste of time. I would record messages into units that are in files and make it possible to replay them in any order, if you need that capability. – Frank Hileman Jun 28 '18 at 17:44
  • I should have been clearer when mentioning the replay feature. The system can be very hard to debug for bugs that happen in production. We have logs we can analyse, but is not allways enough. The replay was considered as a way for us to replay when a costumer has done in their production enviroment in our test env. The idea is to save both network messages and DB querries for later use. I have removed the point, as it probably just adds confusion. – user1038502 Jun 28 '18 at 19:11
  • I kind of like the idea of saving messages and replaying them instead of mocks, but there are some conserns. In my mind, debugging a test when its all code is a lot easier then when you have code and meta data. There is also the problem how to set up all the config and variables that a test would require. This can be done, but I am afraid it would spiral out of control and soon I would be creating my own semi language. The tests would also depend on data which are not contant, its easier to handle that in code then data files. I your idea, but I am not sold right now. Will do some thinking. – user1038502 Jun 28 '18 at 19:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.