GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
I get an exception when I try to access an action which has not been defined in FS configuration.
Why not include an option AssertAllActionsWereConfigured in Tests ...
When it fails would display the Controller/Action or Area/Controller/Action of all which were not defined in FS configuration ...
I like the idea and I have this on the roadmap/todo list but to be honest it's not at the top of the list. If more people ask for it I will make sure it get's some more attention. I'm happy to accept a pull-request for it as well. ;O) Let If you're interested in helping out.
I think that this would be useful ... Similar to AutoMapper's Mapper.AssertConfigurationIsValid().
Am little confused with "AllActions". Is it all the action methods in the assemblies in bin or should we inspect the mvc routes to get the registered routes (aka Controllers/actions) to perform a check against?
When you leave an action out of FluentConfiguration and access that action you get an exception.
So the idea would be to have the method AssertAllActionsWereConfigured() in a test.
This method would search all Controller/Actions existing in a given assembly (aka Controllers/Actions).
You could specify in FS configuration which assemblies to include ... and an option to use ScanAllAssemblies.
This way you can run a test and be sure that every action was covered.
Does it make sense?
Ok.I will take a stab at it and update the thread...
Thanks @shapper @Chandu ... In my humble opinion we should scan all binaries in bin as the default and have an overload for specifying specific assemblies to scan. Does that make sense?
@Chandu You should probably be able to use the AssemblyScanner and the ControllerTypeScanner in the Scanning namespace of FluentSecurity. It is marked as internal but exposed to the TestHelper project. Ping me if you need to bounce any ideas. Thanks!!
@kristofferahl Yes it makes sense to scan all binaries in bin as the default.
@kristofferahl That was my first thought to use the AssemblyScanner and ControllerScanner.. however shouldn't this method be in sync with WhatDoIHave method?
I was thinking to use IWhatDoIHaveBuilder contract and to add a method that returns a list of actions/controllers and policies. We can have a discussion on #jabbr to flesh it out..
Well, as IWhatDoIHaveBuilder is kind of deprecated I wouldn't base anything on that. However, you'll need to do something somilar to what is done in DefaultWhatDoIHaveBuilder to get to the current configuration. I suggest building something that can get all the possible controllers and actions (using AssemblyScanner) and to simply ask the current configuration if there are any policies for that controller action.
In the end it would be great if this "model" was available to use both in the DefaultWhatDoIHaveBuilder and for the Glimpse package. I've been planning to add a similar thing to it anyway. Does this make sense?
I'm always up for a jabbr chat... Maybe later on tonight or tomorrow!?
My bad.....I was not aware IWhatDoIHaveBuilder is deprecated. We can have the default assertion to scan all the assemblies in bin, and provide one more version which accepts a func or some other struct that lets the user define the selection.
Am available for a jabbr session tonight or tomorrow..let me know which one works for you.
Am in EST time..
By default should we scan all assemblies in bin or should we check calling assembly, because in most vanilla cases the all the required controllers are in the calling assembly and scanning all the assemblies in bin is overhead. We can always provide an overload which will force scanning of all bin assemblies.
I agree, it will be overhead in most cases. However, it might be overhead worth having... Maybe @shapper @mariusschulz and @Ridermansb can weigh in on this!?
I think it is worth having ... I have the controllers on the same assembly.
But I know of people which place them in a different assembly.
So it might be useful ...
Are you talking about overhead in development effort or in time consumption when running the tests? A solution to either one of those possibilities would be to give it a lower priority and start with the calling assembly for now (80/20 rule).
@mariusschulz I am talking about overhead during the app startup, if this function in called.
@ALL, I will go ahead with all assemblies in bin folder.