Here's my guess for your first issue: plan tests => 1; is a standard Perl statement, it gets executed at run-time - so it has not yet been executed when you hit the BEGIN block and launch in to your first test.

You could work around this by also putting the plan statement in a BEGIN block. However use Module (foo); is equivalent to BEGIN { require Module; Module->import(foo) }. So its action occurs at BEGIN time, just as required for this case.

I don't have an immediate guess for the second issue. If I were debugging this, my next steps would be a) to run the test program in isolation for more verbose output; then b) to use Devel::Peek to Dump($comp_pass2) directly after setting it - I can think of several types of value that would stringify as "1" but give a false result from $comp_pass2 == 1.

However your expectation of the function also seems odd: normally I would expect a comparator to return similar values to $a cmp $b or $a <=> $b, in particular returning 0 when the two values are equal. With your lengthy test strings it is hard to tell by eye, but I think they are the same.

Here's my guess for your first issue.....it gets executed at run-time - so it has not yet been executed when you hit the BEGIN block and launch in to your first test

That seems sensible. It also seems odd because I didn't write that code - it is part of the boilerplate produced by Module::Starter

I don't have an immediate guess for the second issue

At least I am not missing something obvious :)

$comp_pass2 should contain a floating point between -1 and +1. If the two stringified vectors are the same (like they are in the test), then the result should be +1. The compare method returns the Cosine Similarity of the two vectors derived from the test strings

$comp_pass2 should contain a floating point between -1 and +1.

That could explain the problem - What Every Programmer Should Know About Floating-Point Arithmetic. Is compare guaranteed to return the integer 1 in that case, or could it be returning a floating-point number that is so close to 1 that it is just being shown as 1? (see for example)

is $comp_pass1, 1, 'compare 1';
[download]

Regarding use_ok, I prefer not to use it at all, or test it in a test of its own.

Also note that you can also specify

done_testing(1);
[download]

Thank you.

I already have use_ok in a test of its own so I don't need it here and will remove it.

Off to look at is now :)

UPDATE...it works...
Thanks choroba - it now works :)

I changed:
ok( $comp_pass1 == 1, 'compare 1' ); to is $comp_pass1, 1, 'compare 1';
use_ok to a simple use AI::Embedding; and
done_testing(10); and all(!) tests now pass :)

G'day Bod,

Excellent analysis by ++hv. Here's some additional tips.

Here's a simple test script (pm_11152486_test_more.t):

#!perl

use strict;
use warnings;

use Test::More tests => 3;

my ($var1, $var2) = (1, 2);

# Test1
ok($var1 == $var2, 'Fail: ok()');

# Test2
is($var1, $var2, 'Fail: is()');

# Test3
ok($var2 == $var1, 'Fail: ok()')
    or diag "\$var1[$var1] \$var2[$var2]";
[download]

• Test1: ok() just tells you whether the condition was true or false. The condition can include a wide range of expressions.
• Test2: is() tells you whether the condition was true or false, and the values of the arguments, but the condition is limited to an eq comparison (isnt() uses a ne comparison).
• Test3: Get the best of both worlds: use ok() for any conditional expression; and diag() to get the value of the arguments.

In simple cases, you can interpolate the values of the arguments into the test name; e.g.

ok($var1 == $var2, "Fail: ok($var1 == $var2)");
[download]

in which case, diag() is unnecessary.

In more complex cases, doing this is not easy, or can result in cumbersome test names; or you may want additional information such as values from %ENV. This is where diag() can be particularly useful.

Here's a straightforward run of that code:

$ perl pm_11152486_test_more.t
1..3
not ok 1 - Fail: ok()
#   Failed test 'Fail: ok()'
#   at pm_11152486_test_more.t line 11.
not ok 2 - Fail: is()
#   Failed test 'Fail: is()'
#   at pm_11152486_test_more.t line 14.
#          got: '1'
#     expected: '2'
not ok 3 - Fail: ok()
#   Failed test 'Fail: ok()'
#   at pm_11152486_test_more.t line 17.
# $var1[1] $var2[2]
# Looks like you failed 3 tests of 3.
[download]

Consider the prove utility for additional output information:

$ prove pm_11152486_test_more.t
pm_11152486_test_more.t .. 1/3
#   Failed test 'Fail: ok()'
#   at pm_11152486_test_more.t line 11.

#   Failed test 'Fail: is()'
#   at pm_11152486_test_more.t line 14.
#          got: '1'
#     expected: '2'

#   Failed test 'Fail: ok()'
#   at pm_11152486_test_more.t line 17.
# $var1[1] $var2[2]
# Looks like you failed 3 tests of 3.
pm_11152486_test_more.t .. Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/3 subtests

Test Summary Report
-------------------
pm_11152486_test_more.t (Wstat: 768 (exited 3) Tests: 3 Failed: 3)
  Failed tests:  1-3
  Non-zero exit status: 3
Files=1, Tests=3,  0 wallclock secs ( 0.05 usr  0.02 sys +  0.03 cusr 
+ 0.09 csys =  0.19 CPU)
Result: FAIL
[download]

Use the -v option for verbose output:

$ prove -v pm_11152486_test_more.t
pm_11152486_test_more.t ..
1..3
not ok 1 - Fail: ok()
not ok 2 - Fail: is()
not ok 3 - Fail: ok()

#   Failed test 'Fail: ok()'
#   at pm_11152486_test_more.t line 11.

#   Failed test 'Fail: is()'
#   at pm_11152486_test_more.t line 14.
#          got: '1'
#     expected: '2'

#   Failed test 'Fail: ok()'
#   at pm_11152486_test_more.t line 17.
# $var1[1] $var2[2]
# Looks like you failed 3 tests of 3.
Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/3 subtests

Test Summary Report
-------------------
pm_11152486_test_more.t (Wstat: 768 (exited 3) Tests: 3 Failed: 3)
  Failed tests:  1-3
  Non-zero exit status: 3
Files=1, Tests=3,  0 wallclock secs ( 0.00 usr  0.09 sys +  0.03 cusr 
+ 0.08 csys =  0.20 CPU)
Result: FAIL
[download]

In situations where make test (or other variants of make) has shown some test scripts to have failed; rerun the failed tests individually with as much output as possible. From the same directory that you ran make test, run

prove -vb t/failed_test.t
[download]

In your example, 00-load.t was OK but 01-openai.t was not. So run:

prove -vb t/01-openai.t
[download]

You can run prove with multiple files; I generally don't — normally the output from one file is enough to deal with at once. :-)