1) ClientControllerTest::testCannotUpdateClient
Session missing key: errors
Failed asserting that false is true.
I'm not sure whats wrong. Session::start is called in the initializeVariables method but I don't understand why the errors aren't being added to the session.
You shouldn't have to initialise your session, the unit test will just run as if you were using your application normally. Your session would be initialised in your app, so that session init in the test case would be a double-up.
What do you have in that initializeVariables method? Do you know about the setUp function? You can add a function setUp to your testcase, and anything in there will run before the tests run. Any initialisation required, I'd put in the setUp function.
Also check out the InteractsWithSession trait under vendor/laravel/framework/src/Illuminate/Foundation/Testing/Concerns
@dezgo I had to use Session::start because of a bug. Before I upgraded to 5.2 I had to send the token over manually with each request. There is also a bug within the setUp function that doesn't allow the Database migration and transaction to run properly. I kept ending up with the created records being left in the database. I have looked in the trait but it didn't provide any answers on why the errors variable was missing. Here is my initializeVariables method:
@Jmrtech Regarding the database transactions problem: The way phpunit works results in the setUp method being called before the DatabaseTransactions trait's method has been called. Therefor the transaction gets initiated after you created records within your setup method. Initialize the transaction first thing in your setup method:
Regarding assertSessionHas('errors') failing: It is only flashed to the session so when your assertion is executed it is no longer there. You can see that by displaying the session's contents: dd(session()->all());
If you put something into the session within your authentication before it fails to validate the user, e.g. session()->put('test','something'); you can see that it is still there. If you flash something to the session, e.g. session()->flash('test','something else'); you can see that it is no longer there.
@skliche Ah okay. So this was a logical error on my part. I was under the assumption since that method was available it would be looking for that errors variable, but it makes sense why that variable wasn't there. So since I'm initializing the transaction in the setup can I remove the use statement of the db transaction trait?