Transport Tycoon Forums

I think OpenTTD would benefit from some unit tests. Have there been any efforts to introduce automated testing to the codebase? I'll try and put something together with googletest (https://github.com/google/googletest).

njn wrote:I think OpenTTD would benefit from some unit tests. Have there been any efforts to introduce automated testing to the codebase? I'll try and put something together with googletest (https://github.com/google/googletest).

It might. But it's not easy to actually create/ run any unit tests on OpenTTD. But of course: be our guest

Alright, well in case anyone is interested... I've got a branch going for this here: https://github.com/OpenTTD/OpenTTD/pull/7254

I tried adding some tests for the ReallyAdjustBrightness() function in the 32bpp sse blitter, but I ran into some trouble compiling this object file in a standalone way, because it uses the _screen and _palette externs. This is possibly solvable, though. Anyways, any function with concrete inputs and outputs is a good candidate for unit testing.

njn wrote:because it uses the _screen and _palette externs.

that's what i mean when i say it's hard to introduce unit tests when the program is already done, and not designed with units in mind. you get all theese interdependency issues that makes it difficult to isolate sections to test

njn wrote:I tried adding some tests for the ReallyAdjustBrightness() function in the 32bpp sse blitter, but I ran into some trouble compiling this object file in a standalone way, because it uses the _screen and _palette externs. This is possibly solvable, though. Anyways, any function with concrete inputs and outputs is a good candidate for unit testing.

This is where you will have to introduce some mocking. The palette and screen definitions seem to be pretty straight forward and can probably be defined as static (non-const) data in the test program.

Eddi wrote:

njn wrote:because it uses the _screen and _palette externs.

that's what i mean when i say it's hard to introduce unit tests when the program is already done, and not designed with units in mind. you get all theese interdependency issues that makes it difficult to isolate sections to test

These problems are very solvable.. you can either:
* Make the code more loosely coupled
* Mock out the interfaces that you need to just get things basically working for testing purposes, as jfs points out above. That's probably the route I'll take here, and will give me a chance to try out https://github.com/google/googletest/tr ... googlemock

njn wrote:These problems are very solvable..

yes, but it's an awful lot of grunt work

Eddi wrote:

njn wrote:These problems are very solvable..

yes, but it's an awful lot of grunt work

True.. it can definitely be seen that way. idk why I find it kinda fun / interesting. Maybe it's a personal problem >_<

I guess I like finding overlooked cases that aren't behaving correctly. In fact I already found one: the GreatestCommonDivisor() function can return negative integers when one of its inputs is negative. These should always be positive. This probably doesn't have any effect on the code, since I think it's only using this function with positive integers. But still, GreatestCommonDivisor() gladly accepts negative integers as input, so it might as well be correct.

njn wrote:

Eddi wrote:

njn wrote:These problems are very solvable..

yes, but it's an awful lot of grunt work

True.. it can definitely be seen that way. idk why I find it kinda fun / interesting. Maybe it's a personal problem >_<

In science we have a saying: one person's noise is another person's data. Similar applies to what people consider fun work. Fortunately