Automated tests
Moderator: OpenTTD Developers
Automated tests
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.
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: Automated tests
It might. But it's not easy to actually create/ run any unit tests on OpenTTD. But of course: be our guestnjn 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).
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Re: Automated tests
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.
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.
Re: Automated tests
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 testnjn wrote:because it uses the _screen and _palette externs.
Re: Automated tests
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.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.
Re: Automated tests
These problems are very solvable.. you can either:Eddi wrote: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 testnjn wrote:because it uses the _screen and _palette externs.
* 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
Re: Automated tests
yes, but it's an awful lot of grunt worknjn wrote:These problems are very solvable..
Re: Automated tests
True.. it can definitely be seen that way. idk why I find it kinda fun / interesting. Maybe it's a personal problem >_<Eddi wrote:yes, but it's an awful lot of grunt worknjn wrote:These problems are very solvable..
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.
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: Automated tests
In science we have a saying: one person's noise is another person's data. Similar applies to what people consider fun work. Fortunatelynjn wrote:True.. it can definitely be seen that way. idk why I find it kinda fun / interesting. Maybe it's a personal problem >_<Eddi wrote:yes, but it's an awful lot of grunt worknjn wrote:These problems are very solvable..
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Who is online
Users browsing this forum: FlyveHest and 25 guests