Monthly Archives: April 2013

MVC

How to test “Only certain roles should have access to a controller” in MVC

Leave a comment

Using the TDD approach in an MVC application, I was wondering how can you ensure that only certain roles have access to the controller.  Why should we test for this?  Because this is a clearly defined business rule and all business rules need to have Unit Tests where possible.

This is the code, which is quite simple

[Authorize(Roles = "Administrators")]
public class AdminController : Controller

What we need to ensure is that a developer does not come along and add more roles or take away the Administrators roles.

We can do this using a Test and going through the Controller using reflection, like this:

[TestMethod]
public void AdminControllerShouldOnlyAvailableToAdministrators()
        {
            // Arrange
            var attributes = typeof(AdminController).GetCustomAttributes(true).ToList();
            var countNonAdministrator = 0;
            var countAdministrator = 0;

            // Act
            foreach (var attribute in
                attributes.Where(attribute => attribute.GetType() == typeof(AuthorizeAttribute)).Cast<AuthorizeAttribute>())
            {
                countNonAdministrator = attribute.Roles.Split(',').ToList().Count(role => role.ToString() != "Administrator");
            }

            foreach (var attribute in
                attributes.Where(attribute => attribute.GetType() == typeof(AuthorizeAttribute)).Cast<AuthorizeAttribute>())
            {
                countAdministrator = attribute.Roles.Split(',').ToList().Count(role => role.ToString() == "Administrator");
            }

            // Assert
            Assert.IsTrue(countNonAdministrator  == 0, "Administrators are only allowed to be authorised to use this controller");
            Assert.IsTrue(countAdministrator == 1, "You must only have Administrators to be authorised to use this controller");
        }

 

TFS

The repository layout

Leave a comment

Team Foundation Server provides the ultimate flexibility in terms of how you arrange our data. Because it simply versions directories and files, and because it describes no particular meaning to any of those objects, you may arrange the data in your repository in any way that we choose. Unfortunately, this flexibility also means that it’s easy to find yourself “lost without a roadmap” as you attempt to navigate different Team Foundation Server project repositories that may carry completely different and unpredictable arrangements of the data within them.

To counteract this confusion, you can using a repository layout convention (established long ago) in which a handful of strategically named Team Foundation Server repository directories convey valuable meaning about the data they hold. Most projects have a recognizable “main line”, or trunk, of development; some branches, which are divergent copies of development lines. So we first recommend that each project have a recognizable project root in the repository, a directory under which all of the versioned information for that project—and only that project—lives. Secondly, I suggest that each project root contain a trunk subdirectory for the main development line, a branches subdirectory in which specific branches (or collections of branches) will be created.

In our case branches will contain the developers name followed by the TFS task item they are working on.  This makes it very clear at any time who and what was required.

Trunk would be the main body of development, originating from the start of the project until the present.

Branches will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.

Shelve Pending Changes stores your code changes on the server but doesn’t commit them to the branch. Here are some reasons for using it:

  1. To save changes but undo locally when I’m not ready to commit changes but I need to make an emergency bug fix on the same branch.
  2. To store code for code reviews prior to committing. Other people can check out or view your shelved changes.
  3. To store changes that are ready for committing when the changes aren’t approved yet.

One thing to know about shelving changes: When you unshelve, you get the file as-is. If someone else has modified the file after your shelve, no merge happens. So I don’t recommend shelving changes long-term.

Here are some examples of the structure

$abc[1]\src\csp\trunk

$abc\src\csp\branches\David Jason\3243

$abc\src\csp\branches\David Jason\3122

The repository main root has the following structure and shortened names, this is because Visual Studio has a 260 character name length restriction.

src           Source Code

dep         Deployments

If you are making a large Branch it is recommended that you plan you merge back to your trunk when you branch, as the longer period of time the Branch is separated from the Trunk the more work is going to be required to merge the two back together.  As a rule of thumb one week is acceptable where as one month is much too long and will result in a lot of merge conflicts.  If the branch is out of the main trunk for more than a month then before the code is merged back to the main trunk full testing of the source will be required, both unit tests and system integration testing which will require to be signed off by the test team that it passes full regression testing before the code is merged back to the main trunk.

With larger branches they can have their own trunk and branches while they are being worked on.  If a sub trunk has been created then it is best practice to make sure a build is triggered on all checkins to this trunk to ensure that the code can be build successfully on the build server.  It is important that the above paragraph on merging back is adhered to.


[1] This is the your project level for the Repository; you will find many others as these are historic and should only be used for reference.

SQL

SQL Performance Profiler for SQL Express

Leave a comment

I came across this smart little Profiler for SQL Express, or any version of SQL as it happens.

Microsoft SQL Server family includes free Express edition, that is fully functional, however has some disappointing limitations which prevent from using it in development process. One of them is absense of profiling tools, standard SQL profiler is not included. However, I came across this SQL Performance Profiler to use with the express edition for tuning your system.

SQL Server Express Edition Profiler provides most of functionality standard profiler does, such as choosing events to profile, setting filters, etc. 

It is a small fee of about $5 for three licences, which is well worth the money.

http://www.datawizard.com