Well JFFNMS 0.9.0 was a, well, its a good example of what can go wrong without adequate testing. Having it written in PHP makes it difficult to test, because you can have entire globs of code that are completely wrong but are not activated (because the “if” statement proves false for example) and you won’t get an error.
It also had some database migration problems. This is the most difficult and annoying part of releasing versions of JFFNMS. There are so many things to check, like:
- What has changed between this version of the database?
- Does the development database have all the new fields?
- Will importing an old database and using the diffs give me the same result as importing the new database
- Does the structure field match the object which matches the database table
I’ve been looking at sqlalchemy which is part of turbogears. It’s a pretty impressive setup and lets you get on with writing your application and not mucking around with the low-level stuff. It’s a bit of a steep learning curve learning python AND sqlalchemy AND turbogears but I’ve got some rudimentary code running ok and its certainly worth it (python erroring on un-assigned varables but not forcing you to define them is a great compromise). The best thing is that you can develop on a sqlite database but deploy using mysql or postgresql with a minor change.
Python and turbogears both emphasise automatic testing. Ideally the testing should cover all the code you write. The authors even suggest you write the test first then implement the feature. After chasing down several bugs, some of which I introduced fixing other bugs, automatic testing would make my life a lot easier and perhaps I wouldn’t dread the release cycle so often.
Related articles
- I’m beginning to hate PHP? (abdulapopoola.wordpress.com)
- pTest: PHP Unit Tester in 9 Lines Of Code (blogs.sitepoint.com)
- PHP to the Rescue! (blogs.sitepoint.com)
