Hacker News new | ask | show | jobs
by latch 5534 days ago
My initial point was that the code isn't really unit testable. From what I know, this is common in video games..too much code tied too hardware.

I'm certainly not saying this is bad. I am saying that, from my experience, video game programming is very different than other sorts of programming.
1 comments
palish 5534 days ago
Ah. I gave an example of running a unit test against the hardware. I'd like to understand why it's not really testable? Not to defend myself -- to better myself.
link
latch 5534 days ago
Again, video programming is different..you might want to seek out the advice of people from that field specifically.

We have an analogue in enterprise/web programming. Code that interacts against the database. Do you, or don't you, stub/mock out the data layer code? Traditionally people did mock this out. Then Rails came along with ActiveRecord...and now hitting the DB isn't only common, I think a lot of people agree that, at a point, it's the right approach. Because, after all, what are you really testing if you don't hit an actual DB?

But, that's specific to code that has dependencies on outside systems (like the DB, or your graphic subsystem). When I look at your Foo class and the IsValid method, I see a pretty specific unit that really can and should be tested separately from an actual GrSubsys implementation. I mean, you've given it a dependency on GrSubsys, but I'm not sure that's right.

Should the test read:

"it is invalid when the model is null"

or

"it is invalid when the graphic subsystem returned null"

?

The difference is subtle, but important. The first is decoupled from the implementation. Foo is invalid when it's model is null. The second is coupled to the depedency: Foo is only invalid when the graphic subsytem returned null.

What value does that extra coupling, within your test, get you? What should IsValid (either the test, or the implementation) care that why the model is null? Why add that extra complexity which makes your test more likely to break due to changes to the implementation of the dependency?

If you test Foo independently, and then you test that gGrSubsys returns null on an invalid model separately, the two unit tests end up working together in isolation from changes you might make to the other.

link