@Pikalek a bird!

I'd make a joke with "Oh, I thought it was a squirrel" but that looks really good so I won't

Or do the classic "that's a weird looking dog"

Did you have to make it pee on the branch?

I'm glad that I don't have unit tests. I'd better spend my time hunting bugs than writing and maintaining unit tests.

Never forget that days of debugging can save you hours of writing unit tests.

@nwp or vice versa

I don't have many bugs in the game and I usually find them quickly. And doing boring things like unit tests makes me tired quickly. And a harsh refactoring like now would invalidate all tests.

Then you're doing unit tests wrong.

They have real value when you do them right. They just can't be applied to everything.

I worked in a company that used unit tests in games. They were doing it wrong, obviously.

testing private methods is wrong, isn't it?

In my experience it's extremely helpful for mathy things like collisions, vectors, translations and such. It's easy to put a typo in a formula or thinking you can optimize something that happens to break something.

@trollingchar I think so, but it's not clear where the bug is. It could be that the function is generally useful and should be public and tested.

If the function is not useful, it should not exist at all, or at least marked as deprecated. All functions are useful, but I don't think we should make them all public and tested.

I meant generally useful in the sense of it being reusable.

Maybe "stable" would be a better description.

I'm not that deep into unit testing, but in my experience writing some tests here and there is useful.

You're right. Stable. They were using tests without a stable architecture. That's why they was wrong. I have no stable architecture yet, but also I have no tests, that's why I'm right! But why should I have tests when my architecture is already stable and I'm not going to change it?

You don't test the architecture with unit tests. You test simple functions. Things like bool overlaps(const Triangle &t1, const Triangle &t2);. You don't need a stable architecture to test that.

There must be a bug somewhere in my statement.

ah, these

I usually just double-check these and test them in the game. Maybe this is unprofessional, but it works for me.

@trollingchar The whole idea is that if you do it manually you spend time. It doesn't really have much to do with quality or how professional it is.

So a game that the programmer checked everything themselves is no better or worse than one with tests

That's not true. The tests can be run without the programmer, the programmer checking everything again can't. This becomes relevant when you need to work together with people who may not be as genius as you and then having unit tests telling them they broke something is very helpful.

makes sense

@nwp true, I was speaking more about @trollingchar 's case, where he is working alone on his own project

Even when working alone there are parts of the project you don't work on for months and then need to add a feature. Having tests to make sure you didn't screw up is helpful for that too.

The other thing I want to ask about is dependency injection. It remains unclear to me. What is it and when can it be helpful?

That company used it for the sole purpose of replacing singletons.

@trollingchar That doesn't even make sense.

I too don't understand why they replaced a thing with a more complicated thing

When talking about unit tests it's for when you have a functionality that depends on something else, but you don't want to rely on that something else to test the function. For example you have a camera class that sets the viewport and you want to check that if you use camera.lookat(point); that it sets the viewport correctly. But you don't want an OpenGL window for that, you just want to test the calculation.

So you want to replace the OpenGL window with a little class that just records what the viewport is set to so you can run your test. The problem is now how you manage to make the camera use your fake opengl window. You have to inject that dependency into it somehow. There are various techniques. You can make an opengl window have virtual functions and override them all in your mockup or use templates or even macros to swap out the window.

That's all it means. I have no clue how you'd replace singletons with that.

I asked about dependency injection, not unit tests

That is dependency injection. It literally means injecting a dependency into some piece of code.

It happens outside of unit tests too. Sorting algorithms depend on the comparison function and you have to inject your own custom comparison function into the sorting algorithm. Typically by passing a function in some way.

They used some DI framework and bindings and had annotated fields in classes that were initialized magically with that framework.

In unit tests it's just more difficult. The sorting algorithms are designed with custom comparison functions in mind so naturally they support that. The camera class is not intended to be used without opengl, so naturally it doesn't support the functionality to swap it out. But for testing you still have to do it somehow.

@trollingchar Sounds like the framework makes it easy to swap out fields for whatever the test code wants the fields to be.

now I'm confused completely

Unfortunately dependency injection always seems to make the code worse somehow by either being a hack or allowing something that shouldn't be allowed. I haven't found a solution to that besides living with it.

Wikipedia is probably better at explaining. Just keep in mind that when they say "object" or "service" that that can also be a function or a variable.

I already pass functions as parameters or variables, is it it?

@nwp I didn't - that's the outline for the cursor. I last selected a wide texture brush so it looks like a splatter. Depending on one's perspective, either an unfortunate or hilarious coincidence of location when I did the screen capture.

@trollingchar That probably counts, but it's a trivial case. It gets more interesting when you need to inject a dependency that wasn't meant to be injected. Like a function using a global variable but you want it to use a different one without changing the function. And usually it's about more complex classes that depend on internal state that should be managed by the class but now the test wants to screw with it.

So, is it a workaround for consequences of using global variables?

Global variables is one possible dependency. It could also be a member variable of a class or a function or just about anything the functionality of interest depends on.

It could be the time for when you want to test if a progress bar works correctly and you don't want to wait or something. The progress bar depends on the current time and you want to inject a different dependency into the progress bar so the test can control the time and check if the progress bar works correctly.

I was real excited for dependency injection when I first saw the glossy hype for it. After reading the instructions, less so. I assume it makes sense somewhere, for some folks. Seems like a longer term investment in order to get it to be worth the extra rigging. I stick to more vanilla unit testing, sometimes with mocks & that works well enough for me.

If I'd have to write a program with globals and environment, I'd write a simple wrapper around globals/environment that chooses between real ones and emulation, and that wrapper would be my only global object.

and I'd switch it to emulation mode in "set up" function, which executes before tests

Writing a wrapper and changing the code accordingly is one way of doing dependency injection. Usually though people do not like that their code has an otherwise useless emulation mode. Partially because they don't want all that test garbage in their production code and partially because having different branches for testing and for production defeats the purpose of testing.

Usually you try to make the impact of testing on your code base small-ish.