Originally posted by Remmoze
My friends and I had a heated debate about your usage of `MapPosition(x.5, x.5)` cursor positions on the grid cells in the unit tests. Why do you do that? Why are they not just `MapPosition(x, x)`? Shouldn't it be just the same, but easier to write? And if it's not the same due to a bug, one should just write a different unit test to test specifically for that?
In my opinion, it's better to write `MapPosition(0.5, 0.5)` simply due to the fact that a unit test should get as close to the actual thing it is testing for and nothing else. You can write a different test to test the `x` vs `x.5` ambiguity. And if you accidentally make a bug that cases `x` vs `x.5` product different results, that specific test should fail but not +1000 others as well. The less moving blocks a unit test relies on the better.
In my friends opinion, one should use `MatPosition(x, x)` in the test, but have a test case dependency. The most important assumptions (the fundamentals like `x` vs `x.5...
Read more
It is simple the way the entities exist in the real game.
Transport belt is 1X1 tile entity, and its center is logically in the center of the tile, so the .5 position.
If I built 2X2 entity, like a stone furnace, it wouldn't be on the .5 position in the game, and also in the test.
I'm not even sure, but maybe it would work to just write MapPosition(x,x) for the test, and it would get changed in some of the layers of the logic to the correct position, but then the position of the actual entity would be different than the position I specified in the test, and would make debugging a bit more confusing.
Imagine you create a belt at MapPosition(2,2), and during debugging you find it at (2.5, 2.5). Or even worse: you use the position as a variable to create the entity, and then you use the same position to find the entity to check if it is still there, and since the belt doesn't cover the whole tile, you wouldn't even find the belt on MapPosition(2,2) if you tried to.
...
Read more