Writing test cases for interactive programs is possible and useful : one needs to test the backend of interactions. Unfortunately, this often involves much refactoring if logic and ui are merged into the same routines.

I think that one good way to contribute unit tests it to submit a single test case together with the associated bug fix, and integrate all this with the build system.

Even non-interactive programs can be hard to test properly. For example, a project I am working on: https://code.google.com/p/openmalaria/wiki/Start

This is a simulator, to make predictions — but are the predictions right? Some components I can test individually, but the overall model only via "black box" tests, which tell me no more than whether the result is the same as it was last time I ran that test.

I have lots of testcases for mksh, decent ones too, but the last dozens of bugs are all only caught by actual use, nothing proactively tested, sadly (releases usually have 0 known test failures).

I'm still struggling to pick a project that I think I can add tests to from scratch - choosing a test-suite, format, etc, is non-trivial especially if you need to persuade upstream to use/maintain it.

But yeah, point taken mirabilos, at the point you ship you're almost certainly going to be bug-free. I guess the challenge is adding test-cases as bugs are reported, so you can be sure you've fixed them.

In general, I'd say that "infrastructure" projects might be suitable. By "infrastructure" I mean the software that everyone uses (even if it's only behind the scenes) and that's expected to just work, e.g. software that's shipped in a basic desktop or server install. On the programming side, I'd count tools like a compiler, a linker or a runtime environment as infrastructure projects.

These projects might have some kind of test infrastructure but I'd wager to say that there's usually room for improvement in test coverage.

I'm sure that there are also a lot of infrastructure projects that don't have tests and would love to have somebody writing them.

If you are interested in adding more unit and functional tests, I offer dpkg. :)

It has unit testsuites in the dpkg git repo, for perl code under test/ and scripts/t/, and another one for C code under lib/dpkg/test/. There's also functional testsuites for some dpkg programs under src/t/ and utils/t/. The test coverage is at https://dpkg.alioth.debian.org/coverage/.

In addition there's a functional testsuite for dpkg itself at https://anonscm.debian.org/cgit/dpkg/dpkg-tests.git.

I think it qualifies for your requirements, not sure though if you might want a project that has currently no testsuite. In any case patches welcome!

The MySQL test suite is still there and still being expanded. It is Oracle policy to not publish things that may be security things - i.e. crashing bugs and security bugs don't get public test cases anymore.

Yeah, it sucks and it's the wrong way of doing things... however MySQL is such a small part of Oracle they're not going to get that policy changed any time soon.

That all being said, the MySQL test suite is larger than it has ever been before, so it certainly hasn't gone backwards.

For interactive testing, one can use sikuli to simulate user actions, like clicking on buttons or filling a form. It's in Java, but you can find various bindings out there.

There's even a project using it with selenium and firefox.

The Tails project uses it in its tests already. It's a bit hackish but does work.