| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch got a bit more involved than what was originally planned, but
since we're messing with the tables I decided to do it all right away.
- Moves the constraint definition to the CREATE TABLE statement for the
concerts table. This replaces the existing KEY definition that it had.
- Make sure the venues table is created before the concerts table so
that the above mentioned constraint definition works.
- Rename the tables. Use the wpdb-prefix and make the name a bit
prettier. This caused some changes in the Concert and Venue classes,
and for slightly silly reasons some test classes. The code actually
turned out better (for the most part), but some refactoring can still
be done. The column names remains unchanged for now.
|
| |
|
|
|
|
|
|
| |
Since the date column has changed types, so has the representation in
the concert class.
We should really change the property in the Concert class be a proper
DateTime object.
|
| |
|
|
|
| |
Test that less privileged users don't see all the controls, and that no
controls are rendered on the public facing pages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since we now have code that should be available, both on the public blog
and in the admin section, we need to be more graular when loading the
various parts of the plugin.
We still try to avoid loading admin-only parts for the public blog, but
allways load the parts that we need in either case. Also avoid running
the db migrations when running unit tests, as the schema is copied over
from the dev environment it just caues problems.
Finally, don't hardcode unit tests to always be in_admin, but rather
determine that for each test.
|
| |
|
|
|
|
|
|
|
|
|
| |
There's a bit of setup to make this work as it should, we need to ensure
that the current user and current screen is set to proper values so that
the WordPress api's `is_admin()` and `current_user_can()` work as they
should.
This first test just tests that all the expected forms are being
rendered for the admin user accessing the table through the site admin
interface.
|
| |
|
|
|
| |
Should get rid of most of the annoying output during testing, and allow
moving error handling and logging to the presentation layer.
|
| |
|
|
| |
This also adds a number of new filters to find_concerts.
|
| | |
|
| | |
|
| |
|
|
|
| |
Since the plugin only should load on the admin side, set the WP_ADMIN
constant before loading it in the tests.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Create more of the concerts used by tests into the wpSetupBeforeClass
hook.
|
| |
|
|
|
|
|
|
|
|
|
| |
The commit changes the way we populate the database for the tests by
creating more entries up front. This reduces the amount of duplicated
code between the tests, but also introduce some challenges.
As modifications to the database done in the wpSetUpBeforeClass hook
are not cleaned up automatically by the WP_PHPUnit framework, we also
have to add a wpTearDownAfterClass hook so anything we set up in this
class does not disturb any other tests in other classes.
|
| |
|
|
| |
There's no need to have a separate table (concertlogs) for these fields.
|
| |
|
|
|
| |
Reduce to one find_concerts function taking a filter to limit the
selection.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the concert a full object containing all relevant info, while
we can still segment the data in the db.
Instead of this:
$concert = GiglogAdmin_Concert::get($concert_id);
$venue = GiglogAdmin_Venue::get($concert->venue());
echo "{$concert->name()} @ {$venue->name()} : {$concert->cdate()}"
You can now do:
$concert = GiglogAdmin_Concert::get($concert_id);
echo "{$concert->name()} @ {$concert->venue()->name()} : {$concert->cdate()}"
And yeah, renamed Concert::find_cid() to Concert::get() and changed it's
semantics somewhat. It now either returns the given concert if it
exists, or NULL if it does not. Simpler function; simpler to use.
|
| | |
|
| |
|
|
| |
CSS for edit form in giglog
|
| |
|
|
| |
Added test to create duplicate concert with varied cases in string
|
| |
|
|
|
|
| |
We probably need some better error handling here. There's a myriad of
reasons why this call could fail, and we might need to communicate the
failure reason somewhere.
|
| | |
|
| |
|
|
|
|
| |
The expected attributes did not have names corresponding with the
table columns, which meant that creating a band directly from a returned
table row did not produce the expected result.
|
| |
|
|
| |
Set up a test env before running the test cases.
|
| |
|
|
|
| |
Sidenote: UK is not included in the country list. Did the brexit
everything?
|
| |
|
|
|
|
| |
Not sure if it's a good idea to have `create` return an existing band.
Will have to look at callsites to see if it should be renamed back or if
the callsite should be changed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After much reading I finally found the magic incantations, so now we can
run tests with real database access. This means we no longer need the
primitive $wpdb_stub.
The setup as now _requires_ wp-env, or an environment set up
sufficiently similar. Running in wp-env is the easiest, so aim for that.
I've added a `run-tests` script that will invoke the magic incantation
without having to remember it every time.
To set up for testing:
1. make sure you have composer[1] installed.
2. run `composer install`
3. make sure you have wp-env[2] installed
4. start the wordpress env: `wp-env start`
5. run the tests: `./run-tests`
Let the thousand tests bloom!
[1]: https://github.com/wp-phpunit/wp-phpunit
[2]: https://www.npmjs.com/package/@wordpress/env
|
| | |
|
| | |
|
| |
|
|
| |
Run `reuse lint` to verify that all material is licensed.
|
|
|
This means most static functions now either return a venue object, or an
array of venue objects. The exception is the `all_cities` method, which
still return an array of cities as strings.
The constructor has been made private, as it should not be used directly
from anywhere but the static methods on the Venue class.
|
