I should have assumed this existed, based on Ed Poore’s comment on this post, but here’s the actual command:
System.IO.File.WriteAllText
There are multiple overloads for it, but the most basic one is: File.WriteAllText(filePath,contentString).
I should have assumed this existed, based on Ed Poore’s comment on this post, but here’s the actual command:
System.IO.File.WriteAllText
There are multiple overloads for it, but the most basic one is: File.WriteAllText(filePath,contentString).
I first wrote about NDbUnit back in 2006. Unfortunately, it doesn’t appear much new has happened with the project since then. The current version (1.2) is still a great help for unit testing when you need to put a database into a known state. If an application you’re testing uses strongly-typed datasets as its data access layer (DAL), integrating the use of NDbUnit into your existing unit tests is even easier because it uses XSD files.
I’ve revised my previous sample project using Visual Studio 2008. You can download the source as a zip file. Make sure you have NUnit (I used version 2.4.7) and NDbUnit installed before you attempt to run the sample tests.
While working on some XSD validation code today, I found that I needed to load a couple of text files into strings to unit test. I’d forgotten how I’d done this before, but I googled the answer with this search term:
The top result (at least as of today), gave me the answer I needed. I’ve reproduced it as the following function:
Update: Ed Poore let me know in a comment that the .NET Framework contains a method that does this already. System.IO.File.ReadAllText(path) does the same thing, so you can completely ignore the method above.
Robert Martin is a guy our CEO and architects really respect when it comes to software design and development. Somehow, I managed to not have heard of the guy before this year, so I’ve started reading his stuff. Here are a couple of his older columns that may prove quite useful if you find yourself building APIs in your work:
The first one explains a lot of the issues I’ve seen with applications in previous jobs. In any number of applications, a simple change would have a ripple effect that touched a lot more than just one line of code. Following the open-closed principle more strictly would haved save me many headaches.