* NEW: Add phpunit test for Mo class
Add a unit-level test for the Mo (manufacturing order) class, which
had no direct test coverage yet (RestAPIMoTest.php only exercises
the REST API layer over HTTP, and its most interesting part -
produce/consume - is entirely commented out there).
Covers create() (including the automatic "to produce" line it
creates for the finished product), fetch, update, the
draft -> validated -> canceled -> validated status workflow
(validate/cancel/reopen, including the provisional ref being
replaced on validate()), and delete.
Uses a freshly created specimen Product for fk_product rather than a
random real catalog product: Mo::create() rejects kit/BOM products
unless ALLOW_USE_KITS_INTO_BOM_AND_MO is set, and a specimen product
is guaranteed not to be one.
The module is auto-activated in setUpBeforeClass() if not already
enabled, following the same pattern as the other recently added
tests (activation is real and persists after the test run, it is not
undone by the rollback in tearDownAfterClass - see comment in
setUpBeforeClass() for why).
* FIX MoTest crash in the full test suite (stale $db)
Same class of bug as StockTransferTest (see that commit for the full
analysis): modMrp depends on modBom, which itself depends on
modProduct, whose constructor queries the DB via Societe::useNPR().
If $db is stale/closed when this class's setUpBeforeClass() runs in
the full suite (all classes in one continuous process), activating
modMrp crashes on the dead connection the same way.
Reconnect $db (and refresh $mysoc->db/$user->db, which stashed their
own reference to the old connection at bootstrap) before calling
activateModule(), same pattern as StockTransferTest.
Verified the same way: closing $db and calling
MoTest::setUpBeforeClass() directly reproduces the crash without
this fix and is resolved with it.
* FIX MoTest: resync $mysoc/$user->db unconditionally
Same follow-up fix as StockTransferTest (see that commit for the full
analysis): the previous defensive-reconnect only refreshed
$mysoc->db/$user->db inside the branch where the global $db itself
was detected stale. $mysoc/$user can diverge from a healthy $db
independently (they stash their own ->db reference at bootstrap), so
resync them unconditionally instead.
Verified the same way: closing the original $db but reconnecting only
the global $db variable (leaving $mysoc->db pointing at the closed
one) reproduces the crash with the old code and is resolved with this
fix.
* NEW Centralize the stale-$db reconnect logic in CommonClassTest
Same follow-up as StockTransferTest (#39542): the defensive
reconnect-and-resync-$mysoc/$user logic was duplicated identically
across 3 test classes. Extract it into a shared
CommonClassTest::ensureDbIsConnected() helper so future test classes
that activate a module depending on modProduct don't need to
reimplement it, and so the fix can't drift between test files.
MoTest::setUpBeforeClass() now just calls self::ensureDbIsConnected()
before activateModule().
Re-verified the same way as before: closing the original $db but
reconnecting only the global $db variable (leaving $mysoc->db
pointing at the closed one) still reproduces the crash without this
fix and is resolved with it.
* Remove setUpBeforeClass from MoTest
Removed setUpBeforeClass method to simplify test setup.
* Update CommonClassTest.class.php
---------
Co-authored-by: Laurent Destailleur <eldy@destailleur.fr>
Frédéric FRANCE