Read this and tell me OOP (or at least C#) isn't broken:

https://levelup.gitconnected.com/5-...

All I want to do is mock System.DateTime is for a few of my tests, and I ended up going down this rabbit hole of absolute horseshit: build a custom class that you can mock in tests, blah blah blah blah, uhhhh... YEAH NO

Such a simple functionality / need, and yet there is no easy way to test for it. Sigh.

If you feel like you need to mock data types, (stings, integers, DateTime, etc), you might have a code addiction.

https://youtube.com/watch/...

@PaperTrail How else am I supposed to simulate time passing? At somepoint, you need to mock what the system time is

@PaperTrail haha this video is amazing, I think have much to learn

It's not OOP that is broken, it's STL authors that don't know how OOP works. I have yet to see a language that doesn't fuck this up by the way.

Obtaining the system time is an operation that should be mockable and therefore it should be provided by a service that you can include in your regular DI procedures. The only relation it should have to the DateTime datatype is that the method returns a value of that type.

For Typescript I made an NPM package that wraps Date.now, setTimeout and setInterval in a functionally equivalent (though IMO semantically better) API and also provides a mock for it. This is how it should be structured if we care the slightest bit about object-oriented principles.

https://npmjs.com/package/...

Mocking itself is a hack of a hack

@12bitfloat It's the most natural thing ever if the mocked objects follow the S and the targets follow the I from SOLID

On a second thought, the mock should be able to reuse subsystems of the original implementation, so the mocked object probably also needs to use dependency injection for optimal mockability.

I don't understand why you cannot extend the sys.Time Object, and make any required changes there.

"hurrdurr, OOP is broken because there is an edge case that requires me to do 2 additional minutes of thinking on how to solve a problem" - that's how you sound like ;)

OOP isn't broken.

it's simply not 100% perfect - just like everything else.

You decided to use DateTime.Now everywhere in your code and then you are surprised that you can‘t mock it?

You could have wrapped it into a service which uses DI (being it with OOP principles or even FP with functions, doesn‘t matter). Then using that service everywhere, it would be easy to mock.

So, you decided not to use OOP and you blame OOP for that 😄

@Lensflare

class WrapDateTimeBecauseOOP {

public DateTime GetNow() {

return DateTime.Now;

}

}

nobody else sees a problem with this?

@fullstackchris not sure what you mean. You are missing an interface so that you can exchange the implementation.

But that‘s just one possibility.

One simple way could be to inject the DateTime object itself into other objects that need the current time.

It really depends on what you need.

I‘m not a fan of the classic and mindless DI ceremony with interface/class that is so famous among C# devs.

Anyway, I don‘t see why OOP is the issue here.

Good talk about how oop gets time wrong:

https://infoq.com/presentations/...

class ClockInterface
public function now()

class Clock implements ClockInterface
public function now()

class ClockStub implements ClockInterface
public function now()
public function setStub()

This is basically how you mock/stub services in OOP; especially the current time and randomness. Additionally, you can also wrap DateTime with your own ValueObject.

(c# example from an excellent book about unit- and integration testing: https://livebook.manning.com/book/...)