Automated tests

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Post Reply
User avatar
njn
Engineer
Engineer
Posts: 12
Joined: 11 Jan 2019 03:03
Location: New York, NY
Contact:

Automated tests

Post by njn » 17 Jan 2019 17:49

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).
Last edited by njn on 21 Feb 2019 01:56, edited 2 times in total.

User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9282
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Automated tests

Post by planetmaker » 18 Jan 2019 09:55

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 :)

User avatar
njn
Engineer
Engineer
Posts: 12
Joined: 11 Jan 2019 03:03
Location: New York, NY
Contact:

Re: Automated tests

Post by njn » 21 Feb 2019 01:52

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.
Last edited by njn on 22 Feb 2019 13:27, edited 1 time in total.

Eddi
Tycoon
Tycoon
Posts: 7412
Joined: 17 Jan 2007 00:14

Re: Automated tests

Post by Eddi » 21 Feb 2019 14:26

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
You might not exactly be interested in Ferion, but if you are, have fun :)

User avatar
jfs
Director
Director
Posts: 539
Joined: 08 Jan 2003 23:09
Location: Denmark

Re: Automated tests

Post by jfs » 21 Feb 2019 15:32

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.

User avatar
njn
Engineer
Engineer
Posts: 12
Joined: 11 Jan 2019 03:03
Location: New York, NY
Contact:

Re: Automated tests

Post by njn » 21 Feb 2019 16:14

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

Eddi
Tycoon
Tycoon
Posts: 7412
Joined: 17 Jan 2007 00:14

Re: Automated tests

Post by Eddi » 21 Feb 2019 17:35

njn wrote:These problems are very solvable..
yes, but it's an awful lot of grunt work
You might not exactly be interested in Ferion, but if you are, have fun :)

User avatar
njn
Engineer
Engineer
Posts: 12
Joined: 11 Jan 2019 03:03
Location: New York, NY
Contact:

Re: Automated tests

Post by njn » 22 Feb 2019 13:28

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.
Last edited by njn on 22 Feb 2019 15:01, edited 1 time in total.

User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9282
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Automated tests

Post by planetmaker » 22 Feb 2019 13:40

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 :)

Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 5 guests