Re: RFC: How did I do writing my first test?

My first comment is that tests should be as dumb as possible. This also translates to as superficial and verbose as possible. For example, the use of map in the is_deeply tells me that this should probably be unrolled into a series of is. The reason for this is for ease of test maintenace. Tests are also excellent synopses of what they're testing. I often look at tests to see exactly how the module I want to use is intended to function and some clues on how it operates internally. In other words, tests can be used for additional and indepth documentation for the author and users a like.

Another couple of things: that you don't have to use done_testing and set tests => "14";. If you unroll the is_deeply and base the number of tests on the number of entries in your input files, then go with just the done_testing. This is most useful when the number of tests are based on input length that you may update at some point. Finally, I don't see anything on an initial pass that requires you include use v5.10.0;.

Overall, I think it's great. And it's even greater that you're actually writing a test! :)

Comment on Re: RFC: How did I do writing my first test? Select or Download Code

Replies are listed 'Best First'.
Re^2: RFC: How did I do writing my first test? by Lady_Aleena (Curate) on Sep 24, 2020 at 14:49 UTC
I changed the `is_deeply` to `is`, and all the tests after the one in `BEGIN` failed. The way I read it is this: `is` is for comparing strings, `is_deeply` is for everything else. Since I am comparing two arrays, then I believe I need `is_deeply`. The reason I included `use v5.10.0;` is because it is the minimum version of Perl needed to use the module since it uses `//` (defined or). It makes sense to me to `use` the same version for the test. My OS is Debian 10 (Buster); my perl versions are 5.28.1 local and 5.16.3 or 5.30.0 on web host depending on the shebang. *No matter how hysterical I get, my problems are not* time sensitive. So, relax, have a cookie, and a very nice day!** Lady Aleena	[reply] [d/l] [select]
Re^3: RFC: How did I do writing my first test? by AnomalousMonk (Bishop) on Sep 24, 2020 at 16:33 UTC
... I included `use v5.10.0;` is because it is the minimum version of Perl needed to use the module since it uses // ... To my mind, a `use VERSION;` statement should generally not be in a unit test script, but in the module that is under test. (Of course, there will be odd cases when such a statement needs to be in a test script, but I expect these cases to be rare.) I try to write unit tests to be compatible with the absolute minimum Perl version, although in practice this works out to be version 5.8.8. :) Placing a `use VERSION;` statement as the first statement in a module (and in scripts as needed) as kcott recommends here is part of compile-time checking of environmental requirements. I always include a version assertion except when the code is so generic as to be digestible by even the most hoary version of Perl. Further, having this statement as the first statement in a module as kcott suggests can immediately alert the reader to a minimum version requirement. It is really the business of each module to police its minimum environmental requirements, including Perl version. These requirements may change radically as the module evolves, and you don't want to have to keep track of all that in a test script. Also, a given application may use a wide variety of modules with widely differing minimum requirements. The `use_ok` test will catch a mismatch between a module and the test environment right from the git-go. Give a man a fish: `<%-{-{-{-<`	[reply] [d/l] [select]
Re^4: RFC: How did I do writing my first test? by tobyink (Canon) on Sep 24, 2020 at 20:03 UTC
Though I don't usually include a version requirement in test scripts, for versions >= 5.010 `use VERSION` also loads a feature bundle, and you may wish to use features like `state`, etc in the tests, so it can make sense to do so. toby döt ink	[reply] [d/l] [select]
Re^2: RFC: How did I do writing my first test? by karlgoethebier (Abbot) on Sep 24, 2020 at 11:32 UTC
«I often look at tests to see exactly how the module I want to use is intended to function and some clues on how it operates internally. In other words, tests can be used for additional and indepth documentation for the author and users a like.» I read the friendly manuals. And I’m convinced that tests are not made for additional and indepth documentation. Studying the sources is a different thing. Regards, Karl «The Crux of the Biscuit is the Apostrophe» `perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'`Help	[reply] [d/l]
Re^3: RFC: How did I do writing my first test? by tobyink (Canon) on Sep 24, 2020 at 15:15 UTC
Tests can be useful as additional documentation. Type::Tiny::Manual::AllTypes explicitly links to a directory in the Type::Tiny test suite that is intended to act as in-depth documentation. It tests combinations of things you might not expect to ever see, so perhaps wouldn't see explicitly documented elsewhere, like "should a blessed arrayref pass the type constraint for negative integers?" Certainly most of the test suite is not written with that in mind, but I do think having a test suite that is organized and provides a demonstration of every feature of the software is a worthy goal, and once that goal has been achieved then your tests will act as documentation whether you intended it that way or not. toby döt ink	[reply]