Unit tests for repositories are quite a hassle as we then need to
set up all dependencies in `setUp()` ourselves.
So convert the test to a functional tests where we can rely on the
container to create and initialize the subject for us.
Do not provide the PID where the PID is not relevant to the test.
This allows the reader to see more easily what is relevant for the
test.
Also reduce unnecessary quoting of integers in the DB fixtures.
To prepare for more extended functional controller tests, we now
have a dedicated folder for fixture TypoScript setup, allowing us to have
a clear separation between setup and constants.
The `Product` namespace segment in the domain model namespace
`TTN\Tea\Domain\Model` currently serves no purpose and only adds
confusion. So let's simplify the extension structure accordingly.
(I intended to use this to demonstrate DDD contexts, but never
built enough models in the Tea extension for this to actually
make sense.)
Fixes#1008
This method is deprecated. Starting with TYPO3 11LTS,
`executeFrontendSubRequest` should be used.
Co-authored-by: Daniel Siepmann <coding@daniel-siepmann.de>
We already had this for unit tests, but it was missing for
functional tests.
Also, we do not need to provide a path in this configuration - it
suffices to have this node present in the configuration files.
Closes#1078
That way the extension serves as an example on how to use the TYPO3
internal requests provided by the TYPO3 testing framework.
Those can be used as integration tests.
They are also often easier to set up on existing projects and allow to
refactor the code base, compared to functional and unit tests.
Resolves: #859
The tests now respect the TYPO3 extension key as well as the composer
package name.
There is no more need to use the old (no longer used) typo3conf/ext
path.
Resolves: #739
This makes the fixture more minimal and reduces cross-dependencies
between tests.
Also consistently avoid quotes for integer data in CSV DB fixtures.
Fixes#988
The delete action is triggered using a form with a submit button,
causing a POST request to be sent instead of a GET request.
This is because GET requests should not modify (or delete) data,
but only read it and be idempotent. Also, the request then
is guaranteed to not get cached.
From a usability perspective, a button instead of a link also
is semantically more correct: A link is expected to bring you
to some place, whereas a button is expected to trigger some
action.
Closes#871
This is a pre-patch for adding a CRUD plugin for tea records.
This property contains only the UID of the owner FE user, but not
a relation to a FE user model. This is because we neither have nor
need a FE user model for the purposes of the CRUD plugin.
