Check unittests, including selenium tests, for FAQ.pm

[wollmers]

See also RotherOSS/otobo#682

Selenium tests of installed packages, e. g. FAQ, are not skipped and need adaption.

root@ubuntu:/opt/otobo-docker# grep -i 'selenium' prove_10.0.x_2020-12-28-101043.out
[...]

Can't call method "Get" on an undefined value at /opt/otobo/scripts/test/Selenium/Agent/AgentFAQAdd.t line 25.
[11:03:15] /opt/otobo/scripts/test/Selenium/Agent/AgentFAQAdd.t ........................................................ 
Can't call method "Get" on an undefined value at /opt/otobo/scripts/test/Selenium/Agent/AgentFAQCategory.t line 24.
[11:03:15] /opt/otobo/scripts/test/Selenium/Agent/AgentFAQCategory.t ................................................... 
Can't call method "Get" on an undefined value at /opt/otobo/scripts/test/Selenium/Agent/AgentFAQDelete.t line 24.

[...]

[bschmalhofer]

See also RotherOSS/otobo#512.

[bschmalhofer]

Merged the PR from @wollmers . But for the next release we need to check the tests.

[bschmalhofer]

Reopening.

[bschmalhofer]

For running the tests of an OTOBO package it would nice if the console command Dev::UnitTest::Run were enhanced. Pass the ,sopm file and run only the ,t files that are mentionend in the Filelist.

[bschmalhofer]

The tests for FAQ.pm must still be adapted to the current testing framework. Some more work required.

[bschmalhofer]

Merged the first batch of adaptions. But there are still many test failures. Not sure whether these failures expose real bugs.

[bschmalhofer]

The unit tests look better now:

Test Summary Report
-------------------
/opt/otobo/scripts/test/FAQSearch.t                                   (Wstat: 2816 Tests: 4 Failed: 0)
  Non-zero exit status: 11
  Parse errors: No plan found in TAP output
/opt/otobo/scripts/test/GenericInterface/FAQConnector.t               (Wstat: 5632 Tests: 101 Failed: 22)
  Failed tests:  21-22, 28-29, 35-36, 42-43, 49-50, 56-57 
                63-64, 70-71, 77-78, 84-85, 91-92 
  Non-zero exit status: 22
/opt/otobo/scripts/test/Selenium/Agent/AgentFAQJournal.t              (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
/opt/otobo/scripts/test/Selenium/Agent/AgentFAQLinkObject.t           (Wstat: 768 Tests: 82 Failed: 3)
  Failed tests:  57, 59, 61
  Non-zero exit status: 3
/opt/otobo/scripts/test/Selenium/Agent/AgentFAQSearch.t               (Wstat: 256 Tests: 176 Failed: 1)
  Failed test:  174
  Non-zero exit status: 1
/opt/otobo/scripts/test/Selenium/Customer/CustomerFAQExplorer.t       (Wstat: 256 Tests: 10 Failed: 1)
  Failed test:  10
  Non-zero exit status: 1
/opt/otobo/scripts/test/Selenium/Output/HeaderMeta/CustomerFAQSearch.t (Wstat: 256 Tests: 7 Failed: 1)
  Failed test:  7
  Non-zero exit status: 1
/opt/otobo/scripts/test/Selenium/Output/HeaderMeta/PublicFAQSearch.t  (Wstat: 256 Tests: 5 Failed: 1)
  Failed test:  5
  Non-zero exit status: 1
/opt/otobo/scripts/test/Selenium/Public/PublicFAQExplorer.t           (Wstat: 6400 Tests: 0 Failed: 0)
  Non-zero exit status: 25
  Parse errors: No plan found in TAP output
Files=43, Tests=1892, 188 wallclock secs ( 1.27 usr  0.12 sys + 44.09 cusr  8.25 csys = 53.73 CPU

The failure in FAQSearch.t is interesting . It looks like the mocking of the time did not really work. The first two FAQs should be mocked such that the second FAQ was created 60s after the first FAQ. For getting a clearer picture I added debug info to Field1 and inspected the database. The debug info showed that mocking seems to work, but the create_time does not reflect this.

MariaDB [otobo]> select id, f_field1, created, changed  from faq_item i order by id desc limit 2;
+-----+---------------------------------------------+---------------------+---------------------+
| id  | f_field1                                    | created             | changed             |
+-----+---------------------------------------------+---------------------+---------------------+
| 325 | Updated Field1 Counter: 2, time: 1647626433 | 2022-03-18 17:59:33 | 2022-03-18 17:59:33 |
| 324 | Updated Field1 Counter: 1, time: 1647626373 | 2022-03-18 17:59:33 | 2022-03-18 17:59:33 |
+-----+---------------------------------------------+---------------------+---------------------+
2 rows in set (0.001 sec)

Looks like the create_time and change_time did not consider the mocking.

bes:~/devel/OTOBO/FAQ (issue-#7-unit_tests_take_2)$ TZ=UTC perl -E 'say scalar localtime(1647626373)'
Fri Mar 18 17:59:33 2022

[bschmalhofer]

Did some more debugging concerning the failure in FAQSearch.t. Simply add debug output in Kernel/System/DB.pm:

 575    # Replace current_timestamp with real time stamp.
 576     # - This avoids time inconsistencies of app and db server
 577     # - This avoids timestamp problems in Postgresql servers where
 578     #   the timestamp is sometimes 1 second off the perl timestamp.
 579     my $tt = time;
 580     warn sprintf '%i %i: %s %s', $tt, Kernel::System::UnitTest::MockTime::FixedTimeGet(), scalar localtime($tt),  $Kernel::OM->Create('Kernel::System     ::DateTime')->ToString();
 581     $Param{SQL} =~ s{
 582         (?<= \s | \( | , )  # lookbehind
 583         current_timestamp   # replace current_timestamp by 'yyyy-mm-dd hh:mm:ss'
 584         (?=  \s | \) | , )  # lookahead
 585     }
 586     {
 587         # Only calculate timestamp if it is really needed (on first invocation or if the system time changed)
 588         #   for performance reasons.
 589         my $Epoch = time;
 590         if (!$Self->{TimestampEpoch} || $Self->{TimestampEpoch} != $Epoch) {
 591             $Self->{Timestamp}      =  $Kernel::OM->Create('Kernel::System::DateTime')->ToString();
 592         }
 593         "'$Self->{Timestamp}'";
 594     }exmsg;

show that the fixed time is set, but time still returns the real epoch. Strange. Maybe some other module meddles with CORE::GLOBAL::time() too.

[bschmalhofer]

Failure in FAQConnector.t was due to double slashes in the requested URL. Fixed now.

[bschmalhofer]

@stefanhaerter Could you take a look at the Selenium failures? Passing the issue on to you,