Steve Peters

• About: I occasionally play with the Perl core.

Recent Actions

• Commented on Eating my own dogfood (parallel tests)
  Very interesting. Thanks for posting this....
• Commented on Enterprise Perl
  No swords here. Just bokkens....
• Posted IPv6 functions to Steve Peters

  The past year has been work filled, but its about time to finish up work on the Perl 5 core IPv6 functions. The last bits of functions to work on are getaddrinfo() and getnameinfo(). I'll need to play with Inline::C a bit to try out a few things. At a minimum, it getaddrinfo will look at bit…

Recent Actions from Steve Peters

Comment Threads

• Ovid commented on Eating my own dogfood (parallel tests)

  Roman, if your application code already uses transactions, you'll have to deal with that one a "per app" basis because there are simply too many variables: how it's used, which database you have, are nested transactions allowed, and so on. The main point is catching that prior to the database handle committing to ensure you have test isolation, or use a separate test database that you can throw away, though there's been some discussion on Perl QA about allowing commits to the test database on the theory that tests need to deal with "real" data the same way the application does. I was dead…

• Ovid commented on Eating my own dogfood (parallel tests)

  Joel, I would never use DBICx::TestDatabase because it hard-codes the SQLite driver. I know many people say "use SQLite for a test database", but frankly, I find that if I'm testing on a different database than the one I'm using, I'll get too many divergent behaviors, particularly for larger test suites for code bases where the devs are really taking advantage of the database. For example, here's a custom domain I've created for my Postgresql database:

  
  CREATE DOMAIN percentage AS real
     CONSTRAINT percentage_check
          CHECK ((VALUE >= 0.0) AND (VALUE <= 1.0…

• Davs commented on Eating my own dogfood (parallel tests)

  Based on experience on a relatively small project, using transactions are faster then recreating the database for every single test. Dropping/creating a database is quite faster on SSD or in ramdisk as on HDD.

  For code, that uses transactions already I used to create separate test database - i.e. all the regular tests operate on the same database with transactions (on the beginning of the test i start a transaction, on the end of the test i do a rollback), except that special ones, which use transactions. They operate each on a separate database and those tests does not have transact…

Responses to Comments from Steve Peters