Improving unit tests

[aregtech]

          I also think that tests should not link to areg library, because that will cause us problems when creating mocks

Originally posted by @biwiki in #483 (comment)

[aregtech]

It will not a straight forward task, but for me tests should divided into multiple small ones, each test will contain test class(es), mock class(es) and a subset of classes in production code which is the areg library

To be honest, I’m having difficulty understanding how you envision the proposed code structure. Could you provide a small working example to demonstrate your approach? Using the existing unit tests as a basis for comparison would be perfectly fine. It is to compare the existing solution with your suggestion.

I’m absolutely open to improvements, but since I don’t fully grasp how you intend to organize or structure the code, I’m unable to provide a clear answer at this point.

[aregtech]

@biwiki , I moved our discussion here to merge your fix.

[biwiki]

Nah, it is all about the testing, ie how to create mock interfaces. There is nothing to do with the code structure
I dont see we use mocks in the tests, and if we dont have a plan to do so then that is fine.

[aregtech]

Hi @biwiki,

Ah, I think I’m starting to understand your point, thank you for clarifying! 😊

Mocking is indeed a powerful tool, and I agree that it would be great to have. If not in the current version, it’s certainly worth considering for future updates. To be honest, I don’t yet have enough experience with mocking to manage it effectively. I’d need to either learn more or seek help to get started.

In previous projects where we used mocked interfaces, we typically relied on a dedicated library with testing / mocking utilities containing commonly used platform or framework specific mocked objects. For example, with the AREG framework, this might include objects like ApplicationMock, ServiceManagerMock, TimerManagerMock, and instances of ThreadDispatcherMock, etc.

If you know more practical or straightforward approach to mocking or writing unit tests, I’d greatly appreciate it if you could share. I would be happy to learn!

[biwiki]

I created a simple mock class for implementing os functions under NESocket in this PR #486
And because I cant use NESocket when implementing the functions in the tests, I have to mess up the production code like that
But if the test does not link to posix/NESocketPosix.cpp then I could definitely avoid that

[aregtech]

Thank you, @biwiki, for providing the example. I appreciate it!
hmm... Now understand your approach better. Indeed it is a problem.
Let’s brainstorm and see whether there might be better solution for the issue.

One idea that comes to mind (though I’m not sure if it’s the optimal approach) is to create a NESocketTest.cpp, similar to NESocketWin32.cpp and NESocketPosix.cpp. This file could be compiled and linked into a dedicated areg.test.so or areg.test.dll library, specifically for use in unit tests. In this case, when building the areg project, we would generate and link two libraries:

• areg.so for the core functionality
• areg.test.so for unit testing, assuming unit tests are enabled.

I suggest we use this thread to share more ideas, whether they are great, bad, or even experimental, and evaluate which one offers the most optimal solution.

[biwiki]

Yes, a new library for the tests sounds a good approach to me.
Thanks /biwiki