chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
0 votes

I have been (under) using Typemock for a few years now, and understand how it works, and how to test, but I'm still not using it to its full potential. I'm certainly not Agile!

What I would like to ask are a few questions about the strategy of implementing unit testing. Here's my scenario:
1) Nearly all my programs are C# WinForms programs with the odd exception of Console apps.
2) Over 90% of my programs are GUI apps that use DevExpress components.
3) Over 90% of my programs make extensive use of databases. Mostly SQL Server accessed with the DevExpress ORM (XPO)
4) I sometimes have to connect to legacy data via ODBC.
5) I try to separate functionality from the GUI in Controller classes, and leave just the event handlers in the GUI files.

Okay, here are the questions:
1) As such a high percentage of my app use databases, how should I be testing/mocking these (if at all)?
2) Should I be testing the GUI models (event handlers etc.)? If so, how?
3) As the controller classes accept user input, and return database data, what is the best way of testing these units?

I have been able to mock databases in memory, but the amount of work involved in configuring each test case outweighs the benefits (at least that is what it seems like to me!).

The amount of easily testable code that does not require either GUI intervention and/or database data is very small, so I know I'm doing something wrong!

Any help or advise would be gratefully received.

asked by MartinH (3.2k points)

2 Answers

0 votes
Hi Martin,

Thanks for the feedback. You're asking very big questions, I'll try to keep this answers short.

First, while being agile is a worthy goal, using Typemock does not make you so (I wish, but no). It does help you with implementing unit testing, which is one step in that way.

In terms of strategy, you're on the right track. Separate the UI from the business logic, and that logic from the DAL (generated by XPO). Only the DAL should access the database.

Once you have this in place, testing becomes easier, since your testing controllers and logic components, and mock their dependencies. Mocking the DAL is almost always easier then mocking database calls, and make for more robust tests.

Aim for not having any logic in the GUI. The event handlers should invoke methods on other classes that can be tested separately. If you do have some logic there, it's better to refactor it that way.

I'm impressed with you're mocking the database, but like I said, it's better to fake the DAL that abstracts the database calls. It's much easier this way.

That's the strategy. If you're not there yet, it's ok. You should write tests mocking the current dependencies, and then you can refactor them to get to that situation. I won't lie, it's a process. The main thing is to not lose hope. You're already using the best tools for the job, just remember the end goal.

I hope this was helpful. If not, I'll be happy to explain more.

Gil Zilberfeld
answered by gilz (14.5k points)
0 votes

Yes, your answers were most useful. At least I can see the way forward, and maybe (just maybe) I'm not too far off the goal, but more work is needed.

Probably the most important point is refactoring away the ORM from the business logic; I have not done much of this in the past, but if I do manage to do this, the rest should be plain sailing.

I can see that unit testing is really another skill-set, and just a normal programming skills are learnt over the years, I'm seeing that my use of Typemock is going down the same path. Anyone can pick up a hammer and start hammering, but it take skill to hit the nail on the head every time, and drive it in straight!

answered by MartinH (3.2k points)