Re: Wanted: Spare netbook for a hackathon video link
On Mon, Apr 11, 2011 at 10:55, Ævar Arnfjörð Bjarmason wrote: > On Mon, Apr 11, 2011 at 09:23, Michael G Schwern wrote: >> Hey folks, >> I can't quite make it to the hackathon this year, but I will be able to make >> it to Europe. Long story, but at least I'll be on the right side of the >> planet. >> >> I'd love it if someone could bring a spare netbook with a camera and decent >> microphone they can dedicate as a virtual Schwern. Then I can be there on >> Skype or Google Talk or something and make Ovid's live miserable as usual. :P > > I have asked the relevant booking people if we can use our virtual > conference systems for this purpose. We've arranged a laptop with Skype that'll be connected to a beamer. Can you send me your skype handle so I can have this set up? Thanks.
Re: Wanted: Spare netbook for a hackathon video link
On 2011.4.13 1:03 AM, Ævar Arnfjörð Bjarmason wrote: > We've arranged a laptop with Skype that'll be connected to a beamer. > > Can you send me your skype handle so I can have this set up? Thanks. Thanks! I am cleverly disguised as "Schwern". If you have Google Video Chat setup as well that would be handy. In case Skype flakes out, as it does. -- 3. Not allowed to threaten anyone with black magic. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
post-install testing
Hi, It turned out that there is quite a lot that can go wrong. Found this gem in our internal wiki. :-) My question is regarding the post-install testing. Normally the test are run before installation and then discarded with all the rest of the distribution files. But what possibilities do we have about testing of already installed code? Is anyone working on this concept? Cheers, Jozef
Re: post-install testing
On 2011.4.13 1:50 AM, Jozef Kutej wrote: > It turned out that there is quite a lot that can go wrong. > > Found this gem in our internal wiki. :-) > > My question is regarding the post-install testing. Normally the test are run > before installation and then discarded with all the rest of the distribution > files. But what possibilities do we have about testing of already installed > code? Is anyone working on this concept? Are you talking about integrity testing, making sure the system still has all their pieces and they still work? Or runtime testing, essentially a combination of asserts and logging which run from inside the code to check that the system is internally consistent? For the former, you can run the shipped module tests on your installed code. Run them with prove and leave off the -l. The two issues there is they may want bits of the source directory, so you're best off running it from the original source directory. #2 is the tests might hard code @INC to use the source library so you'll have to find and knock those out. You can also write whatever tests you like, using Test::More and friends, and run them periodically against your installed code. Just make sure they're not destructive. For the latter, there is traditional asserts (Carp::Assert, Carp::Assert::More), and design-by-contract (Sub::Contract) to start. I experimented with putting tests right in the code with Test::AtRuntime. The results go to a log file which can then be watched for failures. It has some issues: it's a source filter; it will chew up memory needlessly storing test history; test functions aren't designed to be fast... but the idea is solid. -- 184. When operating a military vehicle I may *not* attempt something "I saw in a cartoon". -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Re: post-install testing
If you're talking about rerunning the package tests on a module after it's been installed, I had been working on the idea of installing tests along with the code. This would require a few things: 1. A place to install the tests. 2. A way to save the test run history. 3. Possible cooperation from the CPAN, CPANPLUS, CPANM and other maintainers (see point 1). Saving tests could be configurable and then you'd have a test runner which would run all of the tests you've saved. The main thing to keep in mind is that some tests will fail this way (unless you manually hack them to work, such as many database tests or other tests which require resources). So what you want to do when you install a new module is to rerun the "installed" tests and note when you get *different* failures (it's harder than that, to be fair). To do this you need to save the test history and I had started that with https://github.com/Ovid/app--prove--history, but it's an awful hack which I hadn't gotten around to finishing. I'll be at the QA Hackathon here in Amsterdam this weekend, so maybe I should resurrect this idea? Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter- http://twitter.com/OvidPerl/ - Original Message > From: Jozef Kutej > To: perl-qa@perl.org > Sent: Tue, 12 April, 2011 17:50:57 > Subject: post-install testing > > Hi, > > It turned out that there is quite a lot that can go wrong. > > Found this gem in our internal wiki. :-) > > My question is regarding the post-install testing. Normally the test are run > before installation and then discarded with all the rest of the distribution > files. But what possibilities do we have about testing of already installed > code? Is anyone working on this concept? > > Cheers, > Jozef > >
