Open AsafMag opened 6 years ago
Hi, reasons for this approach:
EthernetMonitor
class.controlers
is not goog idea (no real logic inside) and loading/saving code is very similar.How to test your code (just brainstorming):
LoadAllEthBasedInterfaces()
, LoadAllActiveUsers()
, DisableMikrotikUserByName(name)
). It also helps with CQS
. This facade itself is controller
(from my perspective) and should not be unit-tested.ITikConnection
and ITikCommand
(pretend mikrotik communication) - could be very hard workBTW: I have plan to create some kind of mikrotikwrapper class (wraps connection) with easy to use API (like mikrotik.Users.Create(name, ...);
and I will face the same problem there - so - may be, I will recognize I am wrong :-)
D
I would really like to mock
ITikConnection.Save
and many other functions but they are implemented as extension methods. Is that really necessary? What are the reasons for implementing most of the library as extension methods?