Behind this, somewhat, catchy title lies a new version (4.1) of Testing.Commons.NUnit and no golden rule about how to discard potential dates in the digital era (would be rubbish advice anyway).
It is not a major version, but I believe it is an important one since there is a little history behind it.
Because there is little justification besides learning to spend the time upgrading SharpRomans to .NET core.
But learning is fun and quite enough for me.
JSON has become one of the most widely accepted data interchange/representation formats. Not only as a Web data interchange, but also as data representation of multiple document databases.
I cannot say I am a big BDD-er. I have used it for commercial projects, mostly to define complex scenarios for complex pieces of code (a custom discount engine comes to mind) but it comes with a price tag that I am not willing to pay for the majority of tests I write (unit tests).
I am not going to describe what BDD is, philosophy, syntaxes, flavors… I am just going to mention my experience with a couple of tools one can use if developing for the .NET Framework.
Other than showcasing how monetary quantities can be formatted and showing off the data available for different currencies, one of the objectives of NMoneys.Web is showing code samples on how to accomplish common tasks.
Look for my updated comments below.
Back in 2008, I wrote a blog post in order to get a free license of TypeMock (now Typemock Isolator). As a result, I got a free license of the product (which I am thankful even though I have not run it a single time) and a “nice” newsletter subscription.
Before anyone gets confused I am using a very broad definition of contract that it is not related at all with Code Contracts or Design by Contract.
What I mean by contract is the correct implementation of an interface that has become idiomatic. And before you ask, an interface is not a contract. I consider it part of the definition of a contract, but it lacks on the definition of the obligations of client and supplier and most importantly, the verification of such contract. And also before you ask, no, Code Contracts do not provide all the means to express complex obligations and outcomes when conditions are met.
The other day I read an interesting post about testing and a library that might help in some cases, its title is “Introducing the Expected Objects” library. I thought it might be useful and so I spent a spare evening writing some code to check whether is something that could be useful for my team.
Yup, as I mentioned before, after the first “full release” of Testing.Commons, Testing.Commons.NUnit would start to receive more love (and code commits, now that we are at it).
The first version (0.1) has been released. Binaries can be downloaded from NuGet.
I am not going to start another flame war about whether documentation is evil or not.
My personal stand is that is evil but mostly needed.
Configuration in enterprise application is a fact of life.
My take on it is as follows: delay it as late as possible and hard-code in anger until someone asks for a change. Then, accepting the fact that is likely to happen again, the value is pushed into configuration.
GUIDs are precious little things. Useful, annoying at times, but lovable nonetheless. Cherish them as if they were unique (all pun intended) and they will pay your love back.
Face it: time is everywhere and cannot run away from it. That is why I chose time to be the subject of the first release of Testing.Commons, a mere 0.1.
Classes that deal with time in the BCL (DateTime, DateTimeOffset, TimeSpan) might have their issues. They might not be accurate. They might not be correct at all. There might be some better alternatives. But they are not going anywhere, anytime soon.
As the reader might have notice, I am a big advocate of testing. During the years that I have been practicing some flavor of testing I have been developing, borrowing and using small little classes (or bigger ones) and techniques to make my life easier and my code suck a little less.
Anonymous delegates, lambdas and their akin are here to stay and make our life easier.
Despite being in the framework since day one (well, not in their anonymous incarnation and definitely not in their lambda form) delegates have had some sort of “Cambrian explosion” in their usage since the advent of LINQ. More and more developers have been exposed to their benefits and more a more APIs make use of them.
The other day I had an issue with a custom configuration section I would like to talk you about.
My take on configuration is stick as much as possible with .settings configuration until collections, nested elements or some other advance technique is needed. It does not happen often that I need a custom section, though.
My requirements were very simple: a custom configuration element with a mandatory string attribute that must be non-empty.
We left the story in the “how” retrieve the data from the profile system in our tests. Introducing the ProfileTestProvider.
In the previous post we learnt how we could wrap the profile system and test that we could map basic information into more complex objects. In this post we are going to use that profile wrapper as another datasource used to construct more complex and (hopefully) interesting objects.
My team and I have been happily using ASP.Net Membership alongside Forms Authentication to provide authenticated access to private areas of our with zero problems. We have been using the default Sql Server storage, which was a walk in the park after fighting against custom Active Directory access and its security issues.