More often than not, I want to assert that my dependency has been called with a parameter that matches more than one condition.
Let’s say we have a method that calls ICustomerService.Add method.
We want to assert the Add method was called with a Customer that matches a few conditions.
The way we’d typically achieve this is by doing something like this:
var fake = A.Fake<ICustomerService>();
A.CallTo(() => fake.AddCustomer(
c.Property == "123" &&
c.OtherProperty == "345" &&
c.AnotherProperty == "456" &&
c.YetAnotherProperty == "567"
This will work. And it will indeed assert that the AddCustomer method was called with a Customer object, with those properties set to the corresponding values.
The problem lies if one of those properties doesn’t match.
We get a failed test. But no idication of which property it’s failed on.
What I like to do instead, is follow this pattern:
A.CallTo(() => a.Add(A<Customer>._))
.Invokes(c => addedCustomer = c.GetArgument<Customer>(0));
//Individual Asserts on addedCustomer
So, here, we’re basically saying when Add is called, with any Customer object, Invoke the anonymous function, that takes the Customer argument, and stores it in addedCustomer.
We can then individually assert on each property.
I created an issue on GitHub which addresses this, with a view to finding a more ‘inline’ solution
Last night I opened an innocuous looking letter delivered to my home address.
It had a ‘commercial’ postage stamp on it (not one that you’d pick up in the post office) and it wasn’t addressed to anybody on the envelope.
The content of the letter was what I’d expect to get via email – a 419 scam!
It was, however, addressed to the previous occupier of the house. They even knew her husbands name.
Email address listed:[email protected]
As part of a blog post on the LEDS stack (Linux Nginx Dotnet, SQL Server) I’m putting together, I wanted to see how easy it is to install SQL Server on a Ubuntu VM, running on Digital Ocean.
Turns out, very easy.
I went with a Ubuntu 16.04.2 x64 box, with 4GB of RAM
The docs state that you need at least 3.25GB of memory to run SQL Server on Linux.
Once my droplet had created, I SSH’d into it.
First, we need to import the public repository GPG keys, and register the Microsoft SQL Server Ubuntu repository
curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
curl https://packages.microsoft.com/config/ubuntu/16.04/mssql-server.list | sudo tee /etc/apt/sources.list.d/mssql-server.list
Then, it’s a simple
sudo apt-get update
sudo apt-get install -y mssql-server
And SQL Server is installed in around 2-4 minutes.
Next up, it tells you the command you’ll need to run:
for those copying and pasting.
Once you’ve accepted the license terms (you do accept them, don’t you?) and chosen a secure SA password, setup is complete.
You can verify the service is running with:
systemctl status mssql-server
Back in Windows…
To test out your new SQL Server install on Linux, you can connect to it using SSMS (Windows)
I’m currently using SQL Server Management Studio – Release Candidate (17.0 RC3)
(I tested it with 2014, and it worked fine.)
Port 1433 was open on my VM, but it may be blocked with your firewall!
Ok, next let’s get a database up and running on our Linux SQL Server.
I downloaded the Northwind database backup to my local machine.
I used SCP to copy the backup of the Northwind database:
scp Northwind.bak.zip root@:/var/opt/mssql
This copies my Northwind.bak.zip file into /var/opt/mssql on the remote server.
I’m using a mac, so SCP is installed already.
If you’re on Windows, you’ll need to use something like WinSCP
Since I uploaded a zipped backup file, I’ll need to unzip it.
If the unzip command isn’t already installed on your system, then run:
sudo apt-get install unzip
Then it’s just a simple
Next, with SSMS locate the backup file, and restore in the usual way:
Note: SSM puts “C:\” in front of your path in the location bar
This can be ignored, but for some reason it does need to be there.
And there we have it. The Northwind database, restored on to a SQL Server instance, running on Linux, on a non-Microsoft cloud.
I’m currently working on a couple of solutions – one that is Visual Studio 2017 specific, one 2015.
Primarily because the 2017 specific one is full of .net standard projects, and the support is better (or at least, built in)
I wanted to have 2015 use a different theme – I’m only doing small bits in it, but have them both open at the same time, so figured having one light, and one dark (my preferred) would make distinguishing them a lot easier on my multi-monitor setup.
I changed the theme to ‘light’ in Visual Studio 2015. Thought that was that, but almost immediately, 2017 changed to the light them too.
So I changed 2017 back to dark, and you guessed it, the lights went out on 2015.
Turns out that settings are synchronised using your signed in Visual Studio account.
Being signed in as the same user on both editions of Visual Studio was syncing my settings – in real time. Which most of the time would be exactly what I want, however on this occasion, I need to turn it off.
Luckily, there’s a setting for that:
Un-ticking this check-box allows me to have one running in light, one running in dark.
This does of course stop all settings synchronising, so I’m only using it temporarily.
I’ve been a customer of GoDaddy for several years.
Recently, I’ve required to use their support service.
Unusually, they don’t offer email support – just phone, or live-chat
On more than one occasion, live-chat has been unavailable, and making a call hasn’t been convenient.
Secondly, live-chat only works with a persistent connection. Working on a train, for example, means you’ll often be cut off from the live-chat service mid-support session.
This is one reason I’ve been moving most of our domains over to Namecheap.
Their support team is always on hand, both chat and email (I much prefer email where possible)
I realise this is personal preference, but having email support much more suits the way I work – not necessarily always connected!