2 new Laravel things I’m using

Just wanted to share these two simple things I’ve recently found for Laravel 5.3

1. Repository Generator


This packages just removed about half a day of setting up the backend CRUD per. Model / Entity. A few commands, follow the instructions and then boom, you’ve got a fully functional repository class.

Sure, I’d need to write my on Tests around it performing as “expected”, however, I now have a basic Interface and Abstract which I can use across different Models.

2. Laravel Collective “Custom Components”


Laravel Collective packages have been staple Laravel components for a while now, however I’ve never quite got to down all the docs (just whizzed on with the bits I need).

I’ve found the Custom Components part method. Before I’ve been creating a new “HTML Components” service class and linking up blade template files with that, however, now I can just keep it within the HTML Facade without any trouble. Much cleaner!

[ReflectionException] Class LocalUsersSeeder does not exist

Just a quick techie post to help out any other laravelians’ who might hit this issue with Laravel 5.2 and database seeding.

I’ve written a seeder and it keeps failing to seed when I run this,

artisan migrate:refresh ---seed

Class LocalUsersSeeder does not exist

Turns out the quick fix was all I had to do was re-run the

composer dump-autoload

Then it all worked! #HTH

Speed up your Behat testing workflow

So I’m really enjoying Behat and BDD so thought I’d share a cool tip which has sped up my writing test workflow using @tags.

When you need to keep re-running one of your tests you can use tags to make sure you’re only running one thing rather than a whole suite or the whole .feature file.

Basically, in the test you’re working on, add a tag @now

Scenario: Student who has requested an Interview can Apply
When I follow "View"
Then so and so

Now run your test like so,

behat --tags now

It will only ever run that tagged test, so you’re not running loads of others and waiting around. Sometimes, it “feels” even faster to run,

behat --tags now -f progress

I know this may seem pretty simple, but I’m learning here and found this really useful.

State of the union (since starting at Warwick Uni)

A small state of the union post so I don’t forget my journey so far…

The largest change is introducing my Agile experience into many aspects of workflow and to many members of staff.

Agile Training
* I have delivered three separate sets of Agile training
* Once for the Project Management Networking Group
* Once for the WMG IT team
* Once for an individual member of staff

I have introduced some better online tools to support the University’s work
* Trello – The whole IT team use it now to track and collaborate on their work
* Quickcast – The use of screen casting to show staff how to use certain material
* Continuous Integration – GitLab’s CI runner Is now provided by the University following me pushing for access
* Google analytics – To prove that students are using more of their own devices which are Apple based, than the university owned Windows machines
* Twitter Bootstrap must be used across all our custom apps. Our custom built apps from externals had custom CSS wrappers, but now use Twitter bootstrap 3.

Methods of working
* A lot of the Moodle work is “Handle turning”, I have floated the idea of an apprentice, which has led to a summer intern coming in (got ahead of myself, summer interns are always here!)
* IT partners – Following the Agile training, the following ideas of roles and responsibilities of a Product Owner leading and ordering tasks in priorities was taken on for our WMG IT partners
* We use an Agile approach to define what work should be done next. “If it went live tomorrow, what would we need?”

Development Bootstrap
* Deployment
* Folder organistion
* Server registration
* Repository Model
* Interfaces
* Behaviour Driven Development testing
* Unit testing

University Wide
* One of my three University wide ideas has gone onto review stage, using rechargeable mics for presenting will save on batteries and reduce support calls

* Biddr – an online reverse auction. I coached Agile to the staff and also built this learning tool in Laravel 4.
* Gradr – an online app to consolidate marks from multiple modules into one simple dashboard. It provides students a single overview and tutors an overall table of their students marks. I coached the staff in Agile and also built this in Laravel 5.

  • More Project management
  • More Laravel 5 and Elastic Search
  • Improving the University’s IT network (of people, not wires)
  • More training, hopefully in leadership (it’s different here to a small self-owned company!)

Why we test… the two other tests I’m forgetting to write

This morning was spent fixing something, which frankly, I should have known better! However, when you’re coding and project managing on your own, it’s not easy to keep everything rolling.

When I write new Repository methods, I leave a comment note @totest to remind me to come back and write some tests!

However, I’ve missed writing 2 simple types of tests which would have taken 20 mins and then saved me an hour this morning. So I thought I’d share with you lot.

In My Laravel Middleware I have a method which checks the UserId provided is one of our students.

    $user = $this->userRepo->findByUidOrFail($this->fetchUser());

However, because I haven’t filled in any tests on that Repo yet, I’ve been going around the houses trying to fix a problem which some simple unit tests would have flagged 2 days ago. The return wasn’t erroring if the user isn’t there AND was returning a Collection when it should have been giving me a Model

So along with unit testing positive results from a successful method call, we should be writing two other types of tests.

The Exception Test.

Clearly this method name says, find…OR FAIL!!!! However, it wasn’t throwing a ModelNotFoundException on failing, it was just returning a Collection!

The tests I have written to assert it’s working now,

// UserRepositoryInterfaceTest.php /** * @expectedException ErrorException */ public function test_findByUidOrFail_incorrect_params() { $records = $this->theRepo->findByUidOrFail(); } /** * @expectedException IlluminateDatabaseEloquentModelNotFoundException */ public function test_findByUidOrFail_modelNotFound() { $this->theRepo->findByUidOrFail("foo"); }

The returned type Test.

It seems weird to test you’re getting the write variable type back, however, it’s crucially important. Because what if you expect an integer, 2, and you’re returned a string of “2”. Any triple if’s === would fail and probably throw something else off.

So we test for cast types. In this example, I assert the Model by looking for a certain method’s availability or not.

// UserRepositoryInterfaceTest.php

public function test_findByUidOrFail_is_model()
    $record = $this->helper->createAUser();
    $result = $this->theRepo->findByUidOrFail($record->uid);


// TestHelper.php

public function assertIsModel($obj)
        method_exists($obj, 'getTable'),
        'obj is not a Model'

The Repository and Command Pattern…

So I’m a big fan of the Repository Pattern with Laravel. Using interfaces it separates the logic of searching away from the models and also acts as a place to store all your searching commands.


However sometimes I feel like the definition goes to far and needs splitting out. It might only be me making a rod for my own coding back, however, the repository makes sense to me only as a data access place, but not a wrapper for CRUD like operations.

So I split my repos out, there’s a base Class to extend which has some generic methods findOrFail, allPaginate. Then inside each extension are methods which search more specifically for some data.

However, for storing a new model I use a SelfHandling Command / Job.

class ProjectStoreCommand extends Command implements SelfHandling {

and the same for Destroy and Update.

It does make for more tests, but having the repo as a place for too much doesn’t sit right with the cleanliness of a Repository for me.