An open source "Wolf" game-mode tracker for up to 9 players.
| STATUS | GOAL | NOTE |
|---|---|---|
| ☑ | Determine Application Goal | |
| ☑ | Choose Design Pattern | MVC |
| ☑ | Establish project scaffolding | |
| ☑ | Establish server environment | Docker |
| ☑ | Set up unit testing. | PHPUnit |
| ☐ | Work out the hole save logic | |
| ☐ | Write the game mechanix lib | |
| ☐ | Create the final score page |
To work on this stack, first bring it up with:
$ docker-compose up -dThen, install the dependencies with:
$ docker exec -it discwolf_app composer installand look to localhost in your browser.
As it is intended to be a mobile app in the end, test your views on your mobile device by going to your server's IP address.
This package is the bees knees when it comes to manipulating sets of nested arrays (RDBs, and json objects). It's from the laravel team, but I learned how to pull in just this one library. Here's a list of all the methods you can call on it:
https://laravel.com/docs/7.x/collections#available-methods
A tests folder has been added that contains unit tests. The tests/
directory is namespaced in the composer file, and structured to reflect
the app/ directory. Each class in the app/ directory has a class, and
each class has a test class with the same name and the Test suffix. Ex:
./app/Models/Game.php and ./tests/Models/GameTest.php.
Ideally, everything, but that would not be real-world. There's a ton of smart writing on testing philosophies, so we'll just pick a reasonable one for this specific project: "test object interfaces only."
Abstractly, that means, we only test instantiation of, and access to/through the IO points of our objects. Specifically, that means don't bother testing private methods/attributes/properties. The concept being, if something in a private method is messed up in a meaningful way, it will show up as an error in the interface that ultimately relies on that method.
Test Driven Design (sometimes called Behavior D. D.) says you write the tests before writing the feature. The workflow is something like,
- As a user, I want a utility class that does common math for my app.
- I create a unit test class called MathTest.php.
- I create a test asserting that the class exists.
- I run the test and see that it fails. It fails because I didn't write the class yet.
- I write the class stub with namespace.
- I run the test again and it passes.
and on and on and on....
There has to be a balance, and you have to figure out how much TDD you want, or have time/money for.
$ docker exec -it discwolf_app vendor/bin/phpunit tests/