Is this a good test result or do I need to be adding in more tests?

Both! It is good in that the stock tests pass but they are only testing for very basic things - have a read of t/00-load.t to see how little it actually does. What you should do next is write your own tests which actually test your code to show that it does what it is supposed to do and that it handles edge cases as intended, etc.

Also, the skipped: Author tests not required for installation is great for end users but not for you as author. You want to run those yourself so be sure to set the AUTHOR_TESTING environment variable to get them to run for you.

The documentation has now been updated taking into consideration all the feedback people have kindly provided.

I've gone through the documentation and written several tests for each method. Some time ago I read an article about writing tests and cannot find it now. But the one thing that stood out from it was to start writing tests based on the documentation...so that is about what I have done. However, I cannot see a way to test getting an intent as that requires a valid API key. Something that will not be available to the installation scripts. So I have called the method and checked that the success method returns false. Is there a better way to handle the lack of API key?

This has generated some more questions:

There are 30 tests I have created but gmake test says there are 31. Does diag count as a test or does something else account for the discrepancy?

If plan tests => 31 is included I get the error Parse errors: Plan (1..31) must be at the beginning or end of the TAP output. However, plan tests => 31 was autogenerated. I have to use Test::More tests => 31; to get rid of the error. I cannot find any explanation of the error so what does it actually mean?

Are there any other glaringly obvious tests that should be included, but that have been left out?

00-load.t

Read more... (9 kB)

Also just to note in case anyone else finds this in future - the environment variable (on Strawberry Perl at least) is RELEASE_TESTING and not AUTHOR_TESTING

the environment variable (on Strawberry Perl at least) is RELEASE_TESTING and not AUTHOR_TESTING

These are both useful environment variables and they have subtly different uses.

AUTHOR_TESTING should be set only by the author (or maintainer). There are any number of reasons to run author-only tests but these might include tests which run against some sample data set or server application to which only the author has access, etc. But they can also be used for simple tests which the users don't care about such as POD coverage, POD spell checks, etc..

RELEASE_TESTING is for tests run just prior to release. Usually by the author again but these may be the sorts of things that even the author doesn't care about when hacking on the actual code. It is handy for meta-data tests: did you remember to bump the version number, is the Kwalitee OK, etc.

There is also AUTOMATED_TESTING which allows skipping of anything requiring user interaction - handy for CI and the smoke testers.

These three along with NONINTERACTIVE_TESTING and EXTENDED_TESTING are explained in the Lancaster Consensus. It is well worth a read through.

In your case here there is also the important NO_NETWORK_TESTING which, if set, should prohibit anything relying on internet access such as real communications with the Stripe servers.

---

🦛

> Is there a better way to handle the lack of API key?

Coincidentally, I blogged about mocking when I was improving the tests of Net::Stripe.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

There are 30 tests I have created but gmake test says there are 31. Does diag count as a test or does something else account for the discrepancy?

No, diag is not a test, but use_ok is - were you including that in your count?

If plan tests => 31 is included I get the error Parse errors: Plan (1..31) must be at the beginning or end of the TAP output. However, plan tests => 31 was autogenerated. I have to use Test::More tests => 31; to get rid of the error. I cannot find any explanation of the error so what does it actually mean?

Again, this is down to use_ok but this time it is because the use_ok is in the BEGIN block and therefore happens before the plan.

You also have lots of tests like this:

ok( scalar( $stripe->list_products ) == 3,  'Third product added to Tr
+olley' );
[download]

But I would write this instead as:

is scalar( $stripe->list_products ), 3, 'Third product added to Trolle
+y';
[download]

as that will give you better diagnostics if it fails. The ok test should really be used sparingly as all it can test is the truth of its argument. Much better to have something either quantitative or qualitative.

Also, I wouldn't necessarily put all these in 00-load.t as very few of them are to do with loading. You can have as many separate test scripts as you want and by making each one topic-sensitive you can make each one reasonably self-contained and hopefully more manageable.

Are there any other glaringly obvious tests that should be included, but that have been left out?

Too hard to tell without going through your code in detail, but that's why we have Devel::Cover. This will show what you are (and more importantly are not) testing.

However, I cannot see a way to test getting an intent as that requires a valid API key. Something that will not be available to the installation scripts. So I have called the method and checked that the success method returns false. Is there a better way to handle the lack of API key?

You have 2 options here. Firstly you can make the key available to the installation scripts via the environment. This is good because it really tests the interaction with the remote service but may be bad (for some services) because it may require an actual transaction to occur to test your code. Hopefully any remote service you have to deal with will have a testbed.

The other option is mocking. Conversely to the previous option, this is good because it does not require a valid key nor an actual interaction with the remote service but is bad (for you as maintainer) because you will have to work to keep it in step with any interface changes made by the remote service provider. I rather like Test::MockModule for this but there are plenty of other options on CPAN to help you with it.

---

🦛