From jacoby at purdue.edu Tue Mar 12 08:29:48 2013 From: jacoby at purdue.edu (Dave Jacoby) Date: Tue, 12 Mar 2013 11:29:48 -0400 Subject: [Purdue-pm] Meeting in one Week Message-ID: <513F49EC.2090808@purdue.edu> In almost exactly one week, we'll be getting together for the next scheduled meeting of the Purdue Perl Mongers. Do we have ideas for topics? The one thing I have is a curiosity on unit testing. Writing tests is a subject like "eat right", "exercise", "back up your data" and "use revision control", in that I'm convinced by society that these are the right things to do, but in practice, I find myself at a loss on how to go how I currently do them to the glorious new world where I do things right. My issue isn't how to use the *.t syntax and testing modules. My issue is knowing what to test for in the first place. Once I know what to test and how to test, the syntax can and will be learned. I could pull out a module or two and we could determine what should be tested. Or, we could do something else. -- Dave Jacoby Code Maker, Purdue Genomics Core Lab http://web.ics.purdue.edu/~djacoby 391 days until the end of XP support From derrick at csociety.org Tue Mar 12 09:53:16 2013 From: derrick at csociety.org (derrick) Date: Tue, 12 Mar 2013 12:53:16 -0400 Subject: [Purdue-pm] Meeting in one Week In-Reply-To: <513F49EC.2090808@purdue.edu> References: <513F49EC.2090808@purdue.edu> Message-ID: <513F5D7C.1040508@csociety.org> Similarly, we could talk about the different classifications of tests. I find it helpful to think about the level (user,unit,...) which my test is being run to help figure out what I should be writing tests for. https://en.wikipedia.org/wiki/Software_testing I'll try to come up with a quick 5 minute talk about the different levels so we have a base for our conversation. dsk On 03/12/2013 11:29 AM, Dave Jacoby wrote: > In almost exactly one week, we'll be getting together for > the next scheduled meeting of the Purdue Perl Mongers. > > Do we have ideas for topics? > > The one thing I have is a curiosity on unit testing. Writing > tests is a subject like "eat right", "exercise", "back up > your data" and "use revision control", in that I'm convinced > by society that these are the right things to do, but in > practice, I find myself at a loss on how to go how I > currently do them to the glorious new world where I do > things right. > > My issue isn't how to use the *.t syntax and testing > modules. My issue is knowing what to test for in the first > place. Once I know what to test and how to test, the syntax > can and will be learned. > > I could pull out a module or two and we could determine what > should be tested. > > Or, we could do something else. > From bradley.d.andersen at gmail.com Tue Mar 12 09:09:05 2013 From: bradley.d.andersen at gmail.com (Bradley Andersen) Date: Tue, 12 Mar 2013 12:09:05 -0400 Subject: [Purdue-pm] Meeting in one Week In-Reply-To: <513F49EC.2090808@purdue.edu> References: <513F49EC.2090808@purdue.edu> Message-ID: I would really be interested in this as well, and might attend, depending on the day of week. In all the places I have ever worked, we always say we're going to do the leg work before we write any code, or we're gonna do test-driven development. Guess how many *.t files I have ever seen, outside of CPAN? ZERO. Nobody writes tests. And I mean nobody. So I have very limited experience, because I only have time to do what people will pay me to do, and they will never pay me to write tests. And they are all losing money in the end because of it. /bda On Tue, Mar 12, 2013 at 11:29 AM, Dave Jacoby wrote: > In almost exactly one week, we'll be getting together for the next > scheduled meeting of the Purdue Perl Mongers. > > Do we have ideas for topics? > > The one thing I have is a curiosity on unit testing. Writing tests is a > subject like "eat right", "exercise", "back up your data" and "use revision > control", in that I'm convinced by society that these are the right things > to do, but in practice, I find myself at a loss on how to go how I > currently do them to the glorious new world where I do things right. > > My issue isn't how to use the *.t syntax and testing modules. My issue is > knowing what to test for in the first place. Once I know what to test and > how to test, the syntax can and will be learned. > > I could pull out a module or two and we could determine what should be > tested. > > Or, we could do something else. > > -- > Dave Jacoby > Code Maker, Purdue Genomics Core Lab > http://web.ics.purdue.edu/~**djacoby > 391 days until the end of XP support > > ______________________________**_________________ > Purdue-pm mailing list > Purdue-pm at pm.org > http://mail.pm.org/mailman/**listinfo/purdue-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacoby at purdue.edu Wed Mar 13 09:14:04 2013 From: jacoby at purdue.edu (Dave Jacoby) Date: Wed, 13 Mar 2013 12:14:04 -0400 Subject: [Purdue-pm] Meeting in one Week In-Reply-To: <513F5D7C.1040508@csociety.org> References: <513F49EC.2090808@purdue.edu> <513F5D7C.1040508@csociety.org> Message-ID: <5140A5CC.8090105@purdue.edu> So, that sounds like interest. Here are the modules I want to throw in: Beats.pm: outputs time in Swatch Internet Time .beats https://gist.github.com/jacoby/5134618 MyDB.pm: abstracts connecting to MySQL DB https://gist.github.com/jacoby/5153611 DB.pm: abstracts querying MySQL DB. Uses MyDB. https://gist.github.com/jacoby/5153628 On 3/12/2013 12:53 PM, derrick wrote: > Similarly, we could talk about the different classifications of tests. I > find it helpful to think about the level (user,unit,...) which my test > is being run to help figure out what I should be writing tests for. > > https://en.wikipedia.org/wiki/Software_testing > > I'll try to come up with a quick 5 minute talk about the different > levels so we have a base for our conversation. > > dsk > > On 03/12/2013 11:29 AM, Dave Jacoby wrote: >> In almost exactly one week, we'll be getting together for >> the next scheduled meeting of the Purdue Perl Mongers. >> >> Do we have ideas for topics? >> >> The one thing I have is a curiosity on unit testing. Writing >> tests is a subject like "eat right", "exercise", "back up >> your data" and "use revision control", in that I'm convinced >> by society that these are the right things to do, but in >> practice, I find myself at a loss on how to go how I >> currently do them to the glorious new world where I do >> things right. >> >> My issue isn't how to use the *.t syntax and testing >> modules. My issue is knowing what to test for in the first >> place. Once I know what to test and how to test, the syntax >> can and will be learned. >> >> I could pull out a module or two and we could determine what >> should be tested. >> >> Or, we could do something else. >> > > _______________________________________________ > Purdue-pm mailing list > Purdue-pm at pm.org > http://mail.pm.org/mailman/listinfo/purdue-pm -- Dave Jacoby Code Maker, Purdue Genomics Core Lab http://web.ics.purdue.edu/~djacoby 390 days until the end of XP support From jacoby at purdue.edu Wed Mar 13 09:14:49 2013 From: jacoby at purdue.edu (Dave Jacoby) Date: Wed, 13 Mar 2013 12:14:49 -0400 Subject: [Purdue-pm] Meeting in one Week In-Reply-To: <513F5D7C.1040508@csociety.org> References: <513F49EC.2090808@purdue.edu> <513F5D7C.1040508@csociety.org> Message-ID: <5140A5F9.1090509@purdue.edu> Of course, if you have other modules you want to use, send 'em in instead. -- Dave Jacoby Code Maker, Purdue Genomics Core Lab http://web.ics.purdue.edu/~djacoby 390 days until the end of XP support From jacoby at purdue.edu Tue Mar 19 12:23:07 2013 From: jacoby at purdue.edu (Dave Jacoby) Date: Tue, 19 Mar 2013 15:23:07 -0400 Subject: [Purdue-pm] Fix to Beats.pm, as if it matters Message-ID: <5148BB1B.6050000@purdue.edu> DateTime->now() defaults to UTC, so time_in_beats() would have to use DateTime->now( time_zone => 'America/New_York' ) , except that would hard-code it to Eastern US use. So, I suppose the solution is to not have a "use now" option, and perhaps to have it be an output of a DateTime object. Presumably, that's what DateTime::Format::IBeat was, but CPAN won't install it. [1] http://search.cpan.org/dist/DateTime-Format-IBeat/lib/DateTime/Format/IBeat.pm -- Dave Jacoby Code Maker, Purdue Genomics Core Lab http://web.ics.purdue.edu/~djacoby 384 days until the end of XP support From gizmo at purdue.edu Wed Mar 20 08:07:48 2013 From: gizmo at purdue.edu (Joe Kline) Date: Wed, 20 Mar 2013 11:07:48 -0400 Subject: [Purdue-pm] Beginning Perl: testing Message-ID: <5149D0C4.3070507@purdue.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Beginning Perl by Curtis "ovid" Poe has a chapter on Testing. This is probably the most current text on testing. http://ofps.oreilly.com/titles/9781118013847/testing.html At Safari Online: http://my.safaribooksonline.com/book/programming/perl/9781118235638 joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFJ0MQACgkQb0mzA2gRTpnk/QCfU98CR+Xn1Zj5LG0uFhuln0Yo vREAoINyzzaJWhfStlvpNyJMwLNTmvVi =jbNe -----END PGP SIGNATURE----- From gizmo at purdue.edu Wed Mar 20 10:21:40 2013 From: gizmo at purdue.edu (Joe Kline) Date: Wed, 20 Mar 2013 13:21:40 -0400 Subject: [Purdue-pm] Beginning Perl: testing In-Reply-To: References: <5149D0C4.3070507@purdue.edu> Message-ID: <5149F024.40700@purdue.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/20/2013 11:11 AM, Bradley Andersen wrote: > this is great - but how do we get people to _actually_ make testing a > serious, full member of their workflow? > > _that_ was my question from last week. Brad, I'm not sure of a good answer. We started with one of Dave's modules: https://gist.github.com/jacoby/5134618 We decided to make some tests for it, inspired by: http://blogs.perl.org/users/ovid/2013/03/discoverable-tests-and-creating-testing-standards.html In a directory I created the following dirs: lib t in lib was Beats.pm in t was Beats.t Beats.t is: ================================================================ use lib q(/home/jkline/dev/perl/perl-monger/testing-fun/lib); use Beats; use Test::Most; subtest "Verify time_in_beats" => sub { can_ok 'Beats', 'time_in_beats'; }; subtest "Verify no input return" => sub { my $return = Beats::time_in_beats(); ok( defined $return, 'defined'); ok( $return > 0, '> 0'); ok( $return < 1000, '< 1000'); }; use DateTime; my $time = DateTime->now(); subtest "Verify input=now return" => sub { my $return = Beats::time_in_beats($time); ok( defined $return, 'defined'); ok( $return > 0, '> 0'); ok( $return < 1000, '< 1000'); }; my $dt = DateTime->new( year => 1964, month => 10, day => 16, hour => 12, minute => 00, second => 00, nanosecond => 000000000, time_zone => 'America/Chicago', ); subtest "Verify input=noon chicago return" => sub { my $return = Beats::time_in_beats($dt); is( $return,'750.00','noon chicago=750.00'); }; done_testing; ================================================================ We aren't sure if that's the best way to go but it gives us a start. - From Ovid's post and script you get a set of tests that at least checks that all of the subroutines in a module are there. - From there it's just a matter of adding tests and learning the Test'ing syntax. As far as workflow...no clue. I'm still trying to get version control in my work flow (I beg off as being a sysadmin so most of my stuff is short...until it's not :-) joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFJ8CQACgkQb0mzA2gRTpmcUQCcCEQd09VmwmLUX3fGbeyzLoIj JyIAnRPZGS1Yv2DlDmqBpeNhTwKiBXW+ =UB+j -----END PGP SIGNATURE----- From mark at ecn.purdue.edu Wed Mar 20 15:02:59 2013 From: mark at ecn.purdue.edu (Mark Senn) Date: Wed, 20 Mar 2013 18:02:59 -0400 Subject: [Purdue-pm] Beginning Perl: testing In-Reply-To: <5149F024.40700@purdue.edu> References: <5149D0C4.3070507@purdue.edu> <5149F024.40700@purdue.edu> Message-ID: <8689.1363816979@pier.ecn.purdue.edu> Bradley Andersen wrote: | this is great - but how do we get people to _actually_ make testing a | serious, full member of their workflow? Joe Kline wrote: | As far as workflow...no clue. I'm still trying to get version control in | my work flow (I beg off as being a sysadmin so most of my stuff is | short...until it's not :-) The most effective way to have people include testing in the workflow is to not pay them if they don't do it. _Many_ years ago I used a tool I wrote to do unit testing similar to this .t 'sin 0' 0 The first arg would be eval'ed and an error message printed if the result was not equal to the second argument. The terseness and extensibility of this worked well but it was still a lot of work. And for non-trivial code it was as much work to write tests as the code itself. For me, doing better error checking in the code itself (check number of arguments to subs, right types, in right ranges) and writing clear error messages is a much better use of my time. For one-off programs I do the testing during development and when I run it. For programs I run repeatly I sometimes save all the input and output and after I make changes to the program rerun it on all the data and compare it with the output that was checked carefully earlier. Writing tests doesn't do any good unless you check the output carefully! If I remember right, TeX had bug(s) in it for years that would have been eliminated if the original debugging runs were carefully studied. A "summarize email to the postmaster" program I'm working on now has current data set of 346 files with a total of 146 million lines that is used for this regression testing. For example input files are postmaster.120301, postmaster.120302, ... . The first time I run test.pl z120301.1 and z120302.1 are created. Running test.pl gives files that end with .2. Running diff.pl can show differences automatically and ask to delete old files or can be run and have it delete all new files that are duplicates of old files. I only backup xz maximally compressed files and keep the big original files on non-backed up filesystems on the host the program is run on. I use version control in my workflow. Emacs has RCS version control built-in. I prefer to do "rcs -i filename" to initialize, and use "i filename" and "o filename" aliases to check in and out. I _always_ do a rcsdiff before checking in to double check I did everything right. Comments in the source code say when things were checked in and what version it was. (I don't need anything more sophisticated than RCS for most the stuff I do.) Mark Senn