Effective Perl Programming
I now have my copy of the new edition of Effective Perl Programming. I'm halfway through another book, a wedding on the 20th and some other major personal (good) news, so I won't be able to review it right away. However, a few quick notes:
Pros
- Covers 5.12.
- A full chapter on Unicode
- Good discussion of testing
Cons
- Recommends SQLite for a test database (I used to like this idea myself).
- Needs better coverage of Test::Class.
(Can you tell the one chapter I've already read?)
I don't think the testing points are that serious; there needs to be a far more in-depth treatment of testing and for this book, it can't possibly cover this area properly. I also noticed it had nice things to say about Moose, but didn't use it in examples. I think this was the right decision, but I wish it weren't.
And in Web sites it recommends, blogs.perl.org is listed, but use.perl.org is not. Rather interesting.
In any event, those were just a few things I noticed flipping through the book. I'll have a better description later. For now, suffice it to say that it looks very, very good. Just a few of the places I've taken the time to read are well-thought out and show lots of experience.
Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you.
And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/
My English is not stellar, I'm assuming the wedding is yours. If so: congratulations! As people in my country usually say: "Selamat menempuh hidup baru."
What problems do you see using SQLite for a test database?
Only reason I can think of is when using database triggers and procedures.
Got the book myself as well and like it a lot. Well worth the money.
@Robert: here's a quick example from my Veure project:
That's a custom data type and I can do things like:
I can't replicate that in SQLite very easily. This means that if my app screws up and I missed some test coverage (very easy to do), then I possibly won't know about a constraint violation until I push the app to a QA team (who might not find it), our staging servers (where it still might not be found) or our production servers (where our customers will find it).
As apps get more complex and you start relying on views, triggers, stored procedures, or even native data types which SQLite doesn't support very well, you find yourself in the very annoying position of having to either have some (possibly complicated) translation layer to SQLite or you forego much of the promise of correctness that a well-designed database can provide (a properly designed schema can make it extremely hard to insert bad data).
I've only tried three times (that I recall) to use SQLite for a test database. Twice it was a failure as I hit its limitations. The third time was a success — because the app's real database was also SQLite.
I expect that SQLite might be OK for smaller projects where the database is merely used as a glorified, searchable CSV file. For larger projects, I would be very reluctant to rely on it.
@htbaa.myopenid.com: don't get me wrong, I'm also happy with what I've seen. I look forward to reading more.
@Ovid: I wasn't under the impression you're not happy with it. I meant to agree with you about the fact it looks very, very good :-).
When you're using custom data types you're already disabling the use of certain SQL databases (like SQLite and MySQL). It would've been best if this was mentioned, although I think most people know this already.
Since I primarily use MySQL, I prefer to test my application using a MySQL database. Test::mysqld has been a lifesaver for me. It can build a temporary database on the test machine and destroy it after the tests are over. That way I get to test schema deployment/upgrading, triggers and stored routines, and mysql built-in datatypes and functions. Testing in SQLite only misses out on that greatness.
We recommend SQLite as a test database because it's a good enough answer for most Perlers. Obviously, if that doesn't work for you, don't use SQLite. That doesn't mean that everyone else shouldn't use it because it doesn't work in your advanced and complex case.
Another con might be that we don't include the cure for cancer. We would have loved to provide more coverage for Testing, just like we would have loved to provide more coverage for many other topics. However, every book is limited in time and space. We are continuing to add Items that did not make it into the book at the book's website, The Effective Perler. Everyone will find something they think is missing, but that shouldn't detract from all the things that are in the book.
The trouble with big topics such as Testing, however, is that they don't fit into the format of the book. We present short Items that usually assume quite a bit background material. A proper testing book shouldn't use the cookbook style of the Effective Foo series. We left Moose out for the same reason.
Thanks a lot for mentioning Test::mysqld! It made me do a simple search on CPAN which yielded Test::postgresql, which seems to be exactly what I need for consistent database unit testing that can be combined with UI testing on known state of database.
I was thinking the answer might be that you needed something custom that couldn't be tested easily with SQLite.