don't worry, you can stop rolling your eyes and wondering "what's this jerk gonna rant about?" this isn't another 'foo considered harmful' essay. if it were, i would have instead opened it with something pithy, like "while some developers have fixed parrot's bugs, others have added new ones." instead, i'll just get to my points.
parrot has too few tests. in recent times, the normal build cycle has more often than not included the message 'All tests successful' at the end of 'make test'. that, in itself isn't bad, if it's accompanied with a message like ' (1 subtest UNEXPECTEDLY SUCCEEDED).' but in parrot development, this is rarely the case. surely parrot needs more tests. although major portions of parrot remain unspecified and therefore untestable, existing parts of parrot are only partially tested (as evidenced by the almost daily discovery of bugs by HLL designers and other parrot users.) there need to be more tests, including TODO tests for unimplemented and non-working bits. i've discovered that i like adding tests. it's something that i feel confident that i can contribute without making too much of a mess, and the results are immediately visible when 'make test' is run on any platform. writing tests is a task that's always been offered as low-hanging fruit for the willing. i've written a few in the past, here and there, but now i've added quite a number in the past week, and have gotten enough positive feedback that i'm encouraged to do more. parrot development should be more 'test-conscious'. i'm not saying 'test-driven', that doesn't work for all people (although my personal development style is trending toward that method.) i am saying that when implementing a new widget, whenever possible, tests should be written that cover the widget's basic behavior, edge cases, as well as invalid input. if those tests can't be written, for any reason, try to make a comment in the test file to that effect. and, if you can, add a TODO ticket with a short summary of what needs to be done. then others can more easily pick up a small task that somebody else left behind. we're missing some parts of a testing framework. we don't have the ability to write test files in PIR, so we're dependent on a perl install for testing. perl's a great language for writing tests anyway, and right now we're dependent on perl for parrot's configure and build as well. that said, breaking this dependency will make parrot just a bit closer to standing on its own. we're also missing other fancy things like test coverage analysis tools, etc, but these things are not necessary at this stage of test development. there are certain components that require more testing than others at this point. string related functions like escaping still have bugs to be worked out, as do the unicode-related charset and encoding functions. PGE is in need of comprehensive tests, as it's development is active and it's userbase is growing. tests for the parrot ops are incomplete... not all edge cases, invalid input, etc is tested for each op. libraries (pcre, etc) can use more tests, too. of course, there's more, but those are what i see as the most critical. i'm directing my testing efforts firstly at PGE. i'm using S05 / A05 as a reference to develop a comprehensive test suite (including many, many TODO tests.) i see this as a great opportunity not just to improve PGE, but for me to further my understanding of the new and complex perl6 rules syntax. i see no better way to learn it than to systematically test every part. lastly, i'd like to encourage others to join me in adding tests to parrot. parrot tests have been submitted by a large number of developers already, and the suite continues to grow. but your help can make parrot more reliable, maintainable, and better understood by all. ~jerry
