In 3394568, SendingQueue::stopProgress() was refactored to use Doctrine
but a typo introduced a bug causing this method to set
ScheduledTaskEntity::inProgress to true instead of false:
3394568792 (diff-3a26b2d8faf9cc01efd5aef47b058c088c0de01b8074c3be7cefd9adb77fbaaaR551)
This luckly was caught by the
EditorCouponCest.php:seeNoticeWhenCouponCantGenerateAndResumeSending
acceptance test.
This commit fixes the problem and also adds two integration tests to
protect against similar regressions in the future.
[MAILPOET-5682]
While working on the previous commit, I noticed that we had a test to
check removing subscribers that are not part of a segment associated
with a newsletter when sending
(testItRemovesSubscribersFromProcessingListWhenNewsletterHasSegmentAndSubscriberIsNotPartOfIt()).
But SendingQueue::processSending() also handles removing subscribers
when sending newsletters without segments. And there was not test to
cover this part of the code.
[MAILPOET-5682]
This commit also removes Sending::getSendingQueueEntity() as the last
calls to this method were removed when refactoring SendingQueueTest.
[MAILPOET-5682]
It was necessary to update a test to be more lenient when comparing
dates and another one to persist a change in Paris to the database.
[MAILPOET-4368]
This commit changes the SendingQueueTest test class to always use a real
NewslettersRepository object instead of a mock object when instantiating
SendingQueue. This is necessary to prevent false errors in the tests.
Using a mock of the NewslettersRepository in this test class means that
all code inside SendingQueue that uses this repository could behave in
unpredictable ways. As it was happening with a few tests incorrectly
failing after dd6e02e2c16a3a0ef7ad2c12479917e33c312c77:
https://app.circleci.com/pipelines/github/mailpoet/mailpoet/11132/workflows/7b4df151-5a10-48f0-9711-dd590a764880/jobs/192389/tests#failed-test-0
In this case, the code was not changing the status of the newsletter
because findOneById() was returning an empty Newsletter entity instead
of the real Newsletter entity that corresponds to the object in the
database. And, thus, $newsletter->getType() was returning `null` instead
of `standard`.
This problem was already partially addressed in the commit below that
removed some of the usages of the NewslettersRepository mock:
5042cdd15e
[MAILPOET-4363]
In the process it was necessary to change the signature of the method
\MailPoet\Mailer\MetaInfo::getNewsletterMetaInfo() to accept a
SubscriberEntity instead of a Subscriber model and also change
\MailPoet\Cron\Workers\SendingQueue\SendingQueue::processQueue() as it
calls getNewsletterMetaInfo().
Doing this was straightforward, but changing the test class for
SendingQueue was a bit more involved. In particular, the test
SendingQueueTest::testItEnforcesExecutionLimitsAfterQueueProcessing().
This test is a bit brittle and was creating Subscriber models without
saving them to the database with invalid statuses and sources. Switching
getNewsletterMetaInfo() to use entities, while
SendingQueue::processQueue() still uses models, meant that it was
necessary to save the subscribers to the database. Because of this, it
was not possible anymore to use invalid statuses and sources, and
thus, the test changed a bit.
[MAILPOET-4379]
Adds a test whether the personalized values are correct when newsletters get send out
in the SendingQueue with the processing method 'individual'. [MAILPOET-3943]
