Assert All Action Were Configured ... Why not a test? #48

mdmoura opened this Issue Nov 3, 2012 · 15 comments


None yet
4 participants

mdmoura commented Nov 3, 2012


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 ...

Thank You,


kristofferahl commented Nov 5, 2012

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.

/ Kristoffer

mdmoura commented Nov 5, 2012

I think that this would be useful ... Similar to AutoMapper's Mapper.AssertConfigurationIsValid().



Chandu commented Nov 8, 2012

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?

mdmoura commented Nov 8, 2012

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?


Chandu commented Nov 10, 2012

Ok.I will take a stab at it and update the thread...


kristofferahl commented Nov 11, 2012

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!!

mdmoura commented Nov 11, 2012

@kristofferahl Yes it makes sense to scan all binaries in bin as the default.

Thank You,


Chandu commented Nov 11, 2012

@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..


kristofferahl commented Nov 12, 2012

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!?


Chandu commented Nov 13, 2012

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..


Chandu commented Dec 2, 2012

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.



kristofferahl commented Dec 2, 2012

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!?

mdmoura commented Dec 2, 2012


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 ...


mariusschulz commented Dec 2, 2012

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).


Chandu commented Dec 2, 2012

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment