561
edits
Difference between revisions of "OpenTasks"
Jump to navigation
Jump to search
→Generic infrastructure tasks: first version of a subsystem test suite task.
m (→Add support fot Dragon's History game: typos) |
(→Generic infrastructure tasks: first version of a subsystem test suite task.) |
||
| Line 165: | Line 165: | ||
* Refactoring skills. | * Refactoring skills. | ||
* Knowledge of one or more ScummVM platform backends is desirable. | * Knowledge of one or more ScummVM platform backends is desirable. | ||
=== Add a testing framework for ScummVM's subsystems === | |||
''Technical Contact'': [[User:LordHoto|Johannes Schickel]], [[User:Fingolfin|Max Horn]] | |||
''Background:'' | |||
ScummVM is a highly portable application, to achieve that there are different interfaces to access platform specific functionality. Our APIs are usually well documented, thus giving porters and engine authors a clear vision of how different functions / methods are supposed to work. Apart from the lower level platform abstraction APIs we usually offer more high level APIs for engine authors. | |||
For example we have an basic filesystem abstraction API: FSNode. This can be used to browse directories, open files, create new file for writing etc. Since the API is pretty much low level, engine authors would probably create an wrapper around it to ease use. To prevent code duplication and take work from engine authors we introduced our Archive and SearchMan API. SearchMan can be easily used to access game data files without fiddling with FSNode. | |||
Experience has shown that the documentation might be misunderstood, the implementation has some bugs and/or regressions were introduced when doing changes to the code. Currently we have only a very minimalistic test suite in "tests/", and that even only tests container, string and some stream code. Thus it is hard to do proper regression / implementation testing for other APIs, for example FSNode API. | |||
''The Task:'' | |||
As visible from the description above, we need a proper test system to assure our implementations are bug free. There are different approaches for it: | |||
First of all one could add various more tests to our test suite in "tests/". This would require some building system update, since currently we do not link against all of our code for the test suite. Also for ports like PSP or NDS, which can not run those testing suite currently it would not really be useful. Of course on a Linux, Mac OS X or Windows system the test suite would be sufficient to do proper testing. | |||
Another way of adding a test suite is creating a test engine, which tests various APIs. The advantage here is that even ports like NDS and PSP could just run the engine from the main ScummVM binary and await the results. | |||
Both approaches have their advantages, the test suite extension would be easiest to use on Linux etc., while an test engine would be perfectly fine for ports like NDS and PSP. Of course best would be to have both ways. In the end the test engine might be preferable, since it gives us the possibility to test all ports without and real additional work. | |||
Thus the task would be to implement and document a test engine, which tests (preferably) all of ScummVM's subsystems. | |||
''Required Skills:'' | |||
* Reasonable C++ skills. | |||
* Experience with unit tests. | |||
* Knowledge about various ScummVM subsystems would be useful, but not required. | |||
* Knowledge about how to create a new engine for ScummVM would also be useful. | |||
== Audio related tasks == | == Audio related tasks == | ||