If you wish to test specific writelines on a console application: you can do so by adding a StringWriter object to the workflow extensions.
The writeline activity will use the textwriter if it exists as opposed to the console.

[TestMethod]
public void CheckWorkflowWriteLine()
{   
 var wi = new WorkflowInvoker(new HelloWorld());

        //Add string writer to extensions  
 var writer = new StringWriter();    
 wi.Extensions.Add(writer);    
 wi.Invoke();    
 Assert.AreEqual("Hello Workflow", writer.ToString());
}

Hi all.

I've discovered this is not as simple as it would appear to be.
Infact it's worse; in "order" to do this you will need to jump through a few hoops...; in a particular order!

1. Add an activity library project
2. Add a reference to this new project from your WF4 app (any app with workflows.. silverlight/mvc etc)
    ENSURE: this is done before step 3 or visual studio 2010 will give you a circular reference error!
3. In the activity library add the service reference to your webservice
4. Modify your webconfig file to contain the abc information for the connection (servicemodel stuff)
5. Now use the activities (from the toolbox)

I gather from crawling through google that the above sequence is already well defined as a workaround for the vs2010 bug.

It's true what they say, to learn new technologies it's simple a matter of ABC (Always be coding), I've watched manys the video, read many the book but it's only when I went to try to do something the it sinks in.
Like tonight while trying to host a WCF service on my Windows 7 machine I came across a problem that you'd only find by ABC.

HTTP Error 404.3 - Not Found

The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map.

The solution.

Control Panel/Programs and Features/Add or Remove components/Microsoft .NET Framework 3.5.1 section. 

I checked the two Windows Communication Foundation checkboxes shown below (the second box enables Windows Activation Service - WAS so that IIS can host WCF services that can be called using non-HTTP bindings such as TCP) (nice!)

Ok, forget what you learned about workflow in 3.5.

Windows Workflow 4.0

4.0 changes everything you thought you knew about workflow.

WF 4.0 represents a bottom-up rewrite with entirely new thinking. The gains are enormous: custom activities take center stage, and authoring them is much simpler; workflows are entirely declarative; and there are three workflow flow styles that you can combine seamlessly. It's possible that you could see a 10-fold improvement in the time required to create and debug workflows, in addition to 10- to 100-fold runtime performance improvements. You'd also have better control over persistence. Additionally, there's support for partial trust, a completely rewritten designer, and a better debugging experience. One of the most important improvements is in the re-hosting experience. This allows you to create activities and to allow power users -- and others -- to build or modify workflows with the constrained set of activities you've created. Yes, this is possible in WF 3.0/3.5, but the necessary code is challenging, not to mention exceedingly difficult to debug.

The improvements to WF 4.0 come at a cost. Microsoft developed two inter-op strategies to help you over this hurdle. WF 3.0/3.5 will remain part of the framework and will run side by side with WF 4.0. This lets you manage the transition at a time that fits your organization's broader goals. The other inter-op strategy is an inter-op activity that allows you to use WF 3.0/3.5 activities in a WF 4.0 workflow. Workflows are a specialization of activities, so you'll probably be able to run entire 3.0/3.5 workflows inside WF 4.0 workflows.

Screenshot VS2010 B2