sfeldman.NET

We are utilizing NCover to perform code coverage as a part of CI process on the build server. On development machines, at least for now, we don’t have it (which is a bummer). PartCover (a free alternative to NCover) is not there yet, so we waited till the right time would come to buy workstation licenses. It looks like the time is almost right. JetBrains has announced they will release dotCover tool starting with the traditional EAP program (which is well known from R#).

Personally, I am excited. Pretty sure the tool will rock and will give NCover some competition. Looking forward it!

A true asynchronous service operation is not the one that returns void, but the one that is marked as IsOneWay=true using BeginX/EndX asynchronous operations (thanks Krzysztof).

To support this sort of fire-and-forget invocation, Windows Communication Foundation offers one-way operations. After the client issues the call, Windows Communication Foundation generates a request message, but no correlated reply message will ever return to the client. As a result, one-way operations can't return values, and any exception thrown on the service side will not make its way to the client. One-way calls do not equate to asynchronous calls. When one-way calls reach the service, they may not be dispatched all at once and may be queued up on the service side to be dispatched one at a time, all according to the service configured concurrency mode behavior and session mode. How many messages (whether one-way or request-reply) the service is willing to queue up is a product of the configured channel and the reliability mode. If the number of queued messages has exceeded the queue's capacity, then the client will block, even when issuing a one-way call. However, once the call is queued, the client is unblocked and can continue executing while the service processes the operation in the background. This usually gives the appearance of asynchronous calls.

Can’t figure out how to run this combination. Anyone has it going?

Every new BizTalk project has the next line in AssemblyInfo.cs file:

The only way I could solve it was to instruct R# to ignore this error.

Has anyone dealt with it differently?

Specification based testing is kind of testing I prefer. Once in a while I like to see what’s available. This time, it was SpecFlow framework. Based on Gherkin style specification, it creates your specs, nicely integrating with Visual Studio .NET (I used 2008). This is what an output of a test written with SpecFlow looks like in VS2008 (used R# 5 Beta 2 for as a test runner).

Given I have entered 50 and 70 into the calculator
-> done: CalculatorStepDefinition.GivenIHaveEntered50And70IntoTheCalculator() (0.0s)
When I press add
-> done: CalculatorStepDefinition.WhenIPressAdd() (0.0s)
Then the result should be 120 on the screen
-> done: CalculatorStepDefinition.ThenTheResultShouldBe120OnTheScreen() (0.0s)

1 passed, 0 failed, 0 skipped, took 1.75 seconds (NUnit 2.5.3).

(-> done lines are an ugly addition that looked like others didn’t have. Either it was the new R# or something else). In overall, it’s a nice attempt to bring pure specification, readable and meaningful into code. I didn’t like the fact that there were so many artifacts to manage around though. On top of that, refactoring scenarios is not the most pleasant thing in the world, as technically I had to regenerate CalculatorStepDefinition.cs file.

Currently, out of box, SpecFlow is coupled to NUnit, but this is probably something that is just matter of templates re-configuration. I like the attempt, though would not use it on a project that is entirely developed with TDD and is frequently reworked.