Mock Illuminate Config facade without Laravel - testing

I'm working on a package that relies on the Config facade.
The code itself works fine, but I'm encountering issues when testing.
Initially, I was using this code:
Config::shouldReceive('foo.bar')
->andReturn(true);
As many others, I bumped into some issues.
I later read that mocking the Config facade isn't encouraged.
To get around it, most people tend to suggest to use the following instead:
Config::set('foo.bar', true);
Which I reckon works fine, if you're testing from Laravel/Lumen.
But my issue is, I'm not. I just rely on a few Illuminate packages, so that won't work since I get:
RuntimeException: A facade root has not been set.
At this point, some might suggest that I should just inject the Config repository dependency, but I'm using the Config facade in a trait which is used by an Eloquent model, so DI won't work.
Is there any other way I can tackle this?
Thanks!
PS: This question has also been posted on Laracasts

I faced to the same issue. Lumen 5.4
using Config::set('key', 'value') was not worked. So I had to use this way.
//test
use Illuminate\Support\Facades\Config;
Config::shouldReceive('get')
->once()
->with('key')
->andReturn('value');
,
//code
use Illuminate\Support\Facades\Config;
Config::get('key'); //instead config('key');

For those running into a similar issue, I've finally found the correct way to address this problem.
Testing Laravel packages is just what the Testbench package is for.
From the documentation:
To use Testbench Component, all you need to do is extend Orchestra\Testbench\TestCase instead of PHPUnit\Framework\TestCase.
This way, setting a configuration value is just a matter of calling Config::set() as you would on a full Laravel install. No more Mockery issues.

Related

vue3 and sonarqube, data return say: Not covered by tests

hy all,
I state that I have already read the other issues on this problem but I have not found what is right for me, or rather: I believe that sonarqube should not manage my code like this, let me explain:
it signals, in almost all returns, that it failed to run the unit test and, for this reason, the entire application is branded as "failed". But the Vue3 data construct, which uses the default return (doesn't seem complicated and abstruse to me) shouldn't be tested? How could I fix it?
Thank you all.

Initializer does not execute when models reload on Rails 3.1 development environment

We are currently using Ruby 1.9.3, Rails 3.1 (i know, we're working hard to upgrade all our applications).
We're using a module (let's call it 'OurModule' to add a method (let's call it 'OurAddOnMethod' to a model defined in a gem (let'd call that 'GemModel'). We have that module file living in the 'config/initializers' directory.
That file defines the module, and then calls this to include it in the model:
# Include the extension
GemModel.send(:include, OurModule)
When developing, things work well mostly, but periodically we will get an error that basically says "Undefined method 'OurAddOnMethod' in 'GemModel'". Restarting the server resolves the issue (for a while).
I'm assuming this is happening because the models are reloaded periodically with changes made in the development environment, and it appears that the initializers do not also get reloaded at that time..? It seems like this may not be the best way to set things up; it is quite frustrating to deal with.
Can anyone enlighten me on a better way to achieve this?
I ended up using wrapping the code in the following, and keeping it in initializers:
ActionDispatch::Callbacks.to_prepare do
# configure stuff or initialize
end
I feel really bad, i completely missed this question that seems to completely cover mine (linking to the answer that i used):
https://stackoverflow.com/a/8636163/287516

What's the right way to make pickadate play well with browserify?

I've been struggling and very frustrated because I can't find a way to make pickadate play well with browserify. I'm migrating a Backbone app from AMD but pickadate seems impossible to work with it. I must say that I began to use browserify recently so I'm not an expert but I could migrate the rest of my code without any major incident. Of course I'm open to receive some tips and references to master browserify :)
I have jquery and pickadate installed via npm and when trying to use pickadate I'm getting the classic error:
undefined is not a function
I used this way of requiring (note the use without assigning the require to a variable):
require("jquery");
require("pickadate");
I saw this on an answer here at stackoverflow (Requiring pickadate.js with Browserify) but it doesn't work in my case.
Any help or reference about where to find help will be pretty much appreciated.
The current version of pickadate as a module only exposes the instance of PickerConstructor but it doesn't expose DatePicker neither TimePicker so every time we try to instantiate a date picker or time picker we got the error undefined is not a function because neither of them have been loaded and so no jquery.extend invocation have been made to append them to the jQuery object.
What is needed is some kind of facade / wrapper to expose all the pickadate functionality out of the box.
For this I made some small changes directly to the pickadate code base. I added an index.js that works as the facade / wrapper for picker.js, pick.date and pick.time, allowing them to be used out of the box with Browserify by issuing the typical require('pickadate'). It doesn't need to be assigned to a variable since pickadate attaches itself directly to the jQuery object. You can check this gist with the index.js code I used
This change is a copy of the way the CryptoJS library by #evanvosberg exposes its different algorithms through the same pattern implemented in its index.js file.
The only additional change would be to modify the property main in pickadate package.json to point to index.js.
I've just send a message to #amsul, the pickadate author asking for the possibility of integrate this changes directly into the pickadate github repo.
I hope people trying to use pickadate with browserify can find this solution and stop getting frustrated trying to make them play well together!
Greetings to everybody!

AttributeRouting v3.5.6 prefixes and areas not being applied to routes

I've added Tim McCalls AttributeRouting v.3.5.6 via the NuGet package. It seems straight forward enough, but area names and routeprefixes are not being applied to the routes shown in routes.axd.
Has anyone else experienced this?
I found the issue. It is a naming conflict. It appears that RouteArea and RoutePrefix are seen as objects in the System.Web.Mvc namespace, hence are not being applied to the AR routes.
This has been reported to Tim McCall, but he is to busy to work on the AR library anymore. You can see the comment thread here.
I want to be able to use the AR library with MVC5. Namely, because I want to take advantage of the precedence options. If you want to do the same then the following using statements and the conflict seems to resolve.
using AttributeRouting;
using AttributeRouting.Web.Mvc;
using RouteAreaAttribute = AttributeRouting.RouteAreaAttribute;
using RoutePrefixAttribute = AttributeRouting.RoutePrefixAttribute;

Dojo 1.8 Build Layer Modules not available during Parse

In our project we use parse on declarative syntax to instantiate our modules. We have a build process that builds our dojo, generic and functional layers for us. In one of our functions, the parser is complaining that some of the modules aren't defined (What's also odd is that the modules aren't being auto required either). I've confirmed that the layer is included in the page and that the module(s) are included in the layer. I can "require" the modules after the parse and they return the proper constructors. No errors are being reported (the attempt to retrieve the module is in a try/catch).
I feel like something silly is happening, but I can't find it. Any suggestions on how to troubleshoot would be helpful.
I've tried both parseOnLoad (our default) and calling parse seperately, even after a 10 second timeout.
Ugh, I knew it was something silly. We had lang="en" instead of lang="en-US".