When it comes to writing automated tests I have, in the past, tended to ignore the data access layer. Do you really need to test your queries? As long as the code was loosely coupled and I could test everything else, I was happy. After talking at work I was convinced that, in some cases, it might be worth testing your queries themselves in order to check that they’re returning the data that they should be.
This provided a dilemma, because I will always try to avoid writing integration/database tests if I can help it, but how do you test queries without a database? A possible answer is as follows, taken from my post on StackOverflow:
After some deliberation, my colleague and I came up with a way to separate the query from the persistence layer. I threw together a quick example below:
As promised in I have come back to the problem of detecting errors in Visual Studio project files. I have updated the script to now report CS files that are on disk that do not appear in the list of included (and compiled) files in the Project. This has a few limitations, including that it only works with CS files (although the script could be easily amended to look for any file extension you like).
I’ve been prompted to write this post after it cropped up in my office recently, and I was reminded of a job interview I had a couple of years ago. I’ve also seen some discussions online, and wow, some people hate
var. I mean really, really hate it. I even saw one guy in a post saying that if he saw a job applicant using var in an interview he would instantly refuse to hire the guy.
Now, I understand the points that the opponents of
var are making, but I don’t agree. I accept that in the case of:
var data = GetData();
we can’t tell what type “data” is, but this is one of the few examples where this is the case. You might also argue that the method “GetData” has been atrociously named (okay, no arguing, it has been atrociously named), but following most programming rules I’d expect that method to return an object of type “Data”. In this example that’s probably not the case, but it does highlight my point, that this:
My colleague recently introduced me to the eight queens problem (you can read more about it over at Wikipedia). In summary, you have to be able to place eight queens down on a chess board without any of them attacking any other.
This sounds easy at first, but I found that taking a few guesses on a piece of paper yielded no results. Rather than simply solving the problem, I decided it would be more fun to write a program that would find all the solutions for me. I’d been looking for a nice little programming problem to teach myself F# for a while, so I thought I’d give this a go. Well, after a few false starts and a lot of F# Googling, here’s my solution:
CSRF (Cross-Site Request Forgery) is an attack against a website “whereby unauthorized commands are transmitted from a user that the website trusts.” [Wikipedia]. Protection against this attack is essential for any modern web application.
In the case of .NET MVC, Microsoft have implemented an easy-to-use protection method against CSRF. There’s an attribute in the MVC framework that you can put on your controller actions: ValidateAntiForgeryToken. This works well, but it has a few disadvantages:
You must manually decorate all your post actions with the attribute.
It’s easy to forget to do this, so it’s preferable to decorate your entire controller with the attribute (or better yet, a base controller that your whole application uses). Unfortunately, this doesn’t work with the standard ValidateAntiForgeryToken attribute, as this causes all your GET actions to be validated as well (and they will always blow up, as the client doesn’t send any form data with a GET request).
It doesn’t work with ajax posts.
The standard attribute doesn’t work with ajax because it inspects the Request.Form collection when looking for the token field. When you’re making ajax posts this form is always empty. This is the reason I originally started looking for alternative implementations of the anti forgery token validation.
Microsoft is going all-out on .NET 4.5 and C#5’s async feature. Windows RT (the .NET libraries for interfacing with the windows runtime) makes heavy use of task-based asynchrony in the API, and Microsoft’s rule of thumb to all .NET developers is to make any method that can reasonably be expected to take more than 50ms should be asynchronous. This includes web service requests, file read and save operations, and more.
Given the examples in the previous paragraph, most people will instantly think “Well, what about databases?” (as I did). Indeed, so did Microsoft, and they’ve got us covered. Entity Framework 6.0 (currently in alpha state at time of writing) has been updated to support asynchronous queries. What does this look like? Currently there are five methods that make use of asyncrony – SaveChangesAsync() and ExecuteSqlCommandAsync() for non-queries, and FindAsync(), SingleAsync() and ToListAsync() extension methods for IEnumerable.
I’m looking forward to testing this code out to see how it runs. So far I haven’t used async in production code, but from the work I’ve done on my own personal projects, I can say that I’m very impressed with how well .NET async works as well as how easy it is to use.
This is an issue I ran into recently when trying to run some of our regular Powershell scripts recently – they were the same scripts we’d always run but now we were trying to run them remotely (instead of making a person log in over RDP and run a batch file. Very high-tech, I know.) but we were running into an issue to do with the CLR version that gets loaded with your Powershell session.
We’re using our own binaries (written in C#) in our Powershell scripts, and we need v4 of the CLR loaded to get them to run. Normally v2 is what you get, but we found that you can edit the file $pshome\powershell.exe.config with the contents:
<?xml version="1.0"?> <configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0.30319"/> <supportedRuntime version="v2.0.50727"/> </startup> </configuration>
This caused v4 of the CLR to be loaded, but only when you run Powershell locally. If you want to do the same when you remote into the machine, it doesn’t work.
I couldn’t find any documentation on this, but thanks to some nice people on StackOverflow I now have the answer. The configuration file contents above are still what you need, but you need to put them in another file. Two other files actually, if you’re on 64-bit. The files you need are located at
c:\windows\System32\wsmprovhost.exe.config file and
That should be all you need!