Seit Herbst 2008 bietet Microsoft TechNet eine neue Veranstaltungsreihe an: den sogenannten Microsoft TechDay. Im Mai wird sich diese Reihe um das Thema „Administrieren mit PowerShell“ drehen.
“Die Windows PowerShell, zeitweise auch bekannt unter den Codenamen Monad und Microsoft Command Shell (MSH), ist eine von Microsoft entwickelte Alternative zum Windows-Kommandozeilenprogramm cmd.exe und zum Windows Script Host.
Die auf dem .NET-Framework in der Version 2.0 basierende Windows PowerShell verbindet die aus Unix-Shells bekannte Philosophie von Pipes und Filtern mit dem Paradigma der objektorientierten Programmierung. Der Benutzer kann wie bisher einfache Befehle an einer Kommandozeile ausführen und miteinander verknüpfen oder aber auch komplexe Skript-Programme mit der eigens dafür entwickelten PowerShell Scripting Language schreiben.”
[Wikipedia]
Folgende Termine stehen zur Auswahl:
- 05.05.2009: Hamburg
- 06.05.2009: Düsseldorf
- 12.05.2009: Stuttgart
- 15.05.2009: München
Weitere Informationen zur Anmeldung und weiteren geplanten Themen findet man auf der Event-Seite des Microsoft TechDay bzw. auf der Agenda-Seite.
Im Juni wird es dann übrigens eine TechDays-Reihe zu Windows 7 geben. Man darf gespannt sein.
Tags:
microsoft techday,
powershell
"Implementing Microsoft Dynamics NAV 2009" is a new book by David Roys (MVP for Dynamics NAV) and Vjekoslav Babic (Dynamics NAV consultant). It shows the new features of Dynamics NAV 2009 in step-by-step explanations of real-world examples.
If you are interested in this book you can read the complete seventh chapter right here on navision-blog.de:
Chapter 6 (“Modifying the System”) is also available for download.
What the book covers
Chapter 1
The purpose of this chapter is a teaser introduction to get you excited about the product, what’s in it in general, and what’s in it as compared to previous versions, to give you a little taste of what’s coming up in the book, and explain what the fuss about this new release is all about.
Chapter 2
The RoleTailored client is the new user interface for users of Microsoft Dynamics NAV 2009, and it is completely different to the pervious versions. We’ll take you through the different components of the interface, introduce the terminology, explore the navigation components and page types, and teach you how to personalize the application to meet your own requirements using the extensive personalization features.
Chapter 3
Microsoft Dynamics NAV 2009 introduces a new paradigm to ERP. Instead of the system being focused on the forms that capture and present data and the functions the user can perform, the system is based around the individuals within an organization, their roles, and the tasks they perform. We cover how Microsoft researched the roles and explore the departments, roles, and tasks that have been identified in the Microsoft Dynamics Customer Model. We also show the reader how to assign the standard roles to users, how to create new roles, and how to allow departmental super users to configure the application for their role so that the change is applied to all users with the same profile.
Chapter 4
Microsoft Dynamics NAV is not a product with a Next-Next-Finish type of installation, and it takes a lengthy project to deploy it successfully. We focus on the six phases of the implementation process, and explain each phase with detailed dos and don’ts for a typical implementation. Based on the Dynamics Sure Step implementation methodology with advice liberally sprinkled throughout, special attention is given to new features of Microsoft Dynamics NAV 2009, and where the new capabilities must be taken into account to make most out of the implementation project.
Chapter 5
Every implementation of Microsoft Dynamics NAV 2009 will require the system to be configured to meet the needs of the business. This chapter tells the implementation consultant how to do this from a core financials perspective and provides valuable information that will allow developers to understand more about the application they are changing. We cover basic accounting for programmers, dimensions, and posting groups, and how to use the Rapid Implementation Methodology (RIM) Toolkit to speed things along.
Hardly any standard system can fit the needs of a business out of the box. Either the customer must shape their processes to match the system, or the consultant must shape the system to match the processes, and usually the latter prevails. This chapter explains the process of modifying the system, how to design a viable data model, and how to design and develop a functional user interface for both RoleTailored and Classic clients, without writing any code.
The three-tiered architecture of Microsoft Dynamics NAV 2009 and native Web Services Enablement open up a whole new world of possibilities for NAV implementations. We cover some of the many possibilities for extending the application, allowing the consultant and developer to understand the technologies that are available and their respective design considerations. Our practical examples introduce the NAV programmer to the world of .NET and show how you can use the information available on the internet to develop your own killer .NET add-ons.
Chapter 8
There’s much more to development than programming. It starts with understanding what customer really needs, and usually extends way beyond the system being deployed to a test environment. This chapter focuses on the development phase, and what it takes to get from a concept to a live and working solution.
Chapter 9
After the system goes live, or as it grows, there are periods when new problems may arise, and often their source is far from obvious. This chapter explores the tools and techniques available for detecting problems, pinpointing the source, and helping to remove them from the system quickly and painlessly. It explains how to debug the Service Tier, how to troubleshoot performance issues, what can be done to avoid problems, and how proper planning before design can help to get it right the first time.
Chapter 10
Our sample application focuses on requirements gathering, functional specification creation, solution design, and the eventual build of a prototype. We look at how a business problem can be explored using techniques such as interviewing, use-case modeling, and object-role modeling to create a solution design that can be molded into a working prototype.
If you want to get more information about the book visit: http://www.packtpub.com/implementing-microsoft-dynamics-nav-2009/book
Tags:
Dynamics NAV 2009,
Navision
In my last article I showed two ways to use parameterized scenarios in NaturalSpec. This time I will show how we can combine both to test a small Quicksort function.
First of all we define a scenario for sorting:
/// predefined sorting scenario
let sortingScenario f list =
Given list
|> When sorting_with f
|> It should be sorted
|> It should contain_all_elements_from list
|> It should contain_no_other_elements_than list
/// predefined Quicksort scenario
let quicksortScenario list = sortingScenario QuickSort list
Now we define some concrete test cases:
[<Scenario>]
let When_sorting_empty_list() =
quicksortScenario []
|> Verify
[<Scenario>]
let When_sorting_small_list() =
quicksortScenario [2;1;8;15;5;22]
|> Verify
[<ScenarioTemplate(100)>]
[<ScenarioTemplate(1000)>]
[<ScenarioTemplate(2500)>]
let When_sorting_ordered_list n =
quicksortScenario [1..n]
|> Verify
[<ScenarioTemplate(100)>]
[<ScenarioTemplate(1000)>]
[<ScenarioTemplate(2500)>]
let When_sorting_random_list n =
quicksortScenario (list_of_random_ints n)
|> Verify
After we defined our spec the task is now to implement the sorting function. I am using a very short (and very naïve) Quicksort implementation in F#:
/// naive implementation of QuickSort - don't use it
let rec quicksort = function
| [] -> []
| pivot :: rest ->
let small,big = List.partition ((>) pivot) rest
quicksort small @ [pivot] @ quicksort big
let QuickSort x =
printMethod ""
quicksort x
If we run the scenario, we get the following output (I shortened a bit):
Scenario: When sorting empty list
– Given []
– When sorting with QuickSort
=> It should be sorted
=> It should contain all elements from []
=> It should contain no other elements than []
==> Result is: []
==> OK
==> Time: 0.0355s
Scenario: When sorting small list
– Given [2; 1; 8; 15; 5; 22]
– When sorting with QuickSort
=> It should be sorted
=> It should contain all elements from [2; 1; 8; 15; 5; 22]
=> It should contain no other elements than [2; 1; 8; 15; 5; 22]
==> Result is: [1; 2; 5; 8; 15; 22]
==> OK
==> Time: 0.0065s
Scenario: When sorting ordered list
[…] 100 elements
==> OK
==> Time: 0.0939s
Scenario: When sorting ordered list
[…] 1000 elements
==> OK
==> Time: 0.7130s
Scenario: When sorting ordered list
[…] 2500 elements
==> OK
==> Time: 3.0631s
Scenario: When sorting random list
[…] 100 elements
==> OK
==> Time: 0.0485s
Scenario: When sorting random list
[…] 1000 elements
==> OK
==> Time: 0.1878s
Scenario: When sorting random list
[…] 1000 elements
==> OK
==> Time: 0.8713s
As you can see the function is much faster if we sort a random list. This is because of the naïve choice of the pivot element.
I don’t want to give better implementations here (use LINQ or PLINQ). I just wanted to show how we can easily verify a test function with NaturalSpec.
Tags:
F#,
NaturalSpec,
quicksort
I wrote a lot about NaturalSpec in my last articles. This time I will show how we can use parameterized scenarios.
1. Using predefined scenarios
By writing predefined parameterized scenarios we can easily create a scenario suite with lots of different test cases:
// predefined scenario
let factorialScenario x result =
Given x
|> When calculating factorial
|> It should equal result
[<Scenario>]
let When_calculation_factorial_of_1() =
factorialScenario 1 1
|> Verify
[<Scenario>]
let When_calculation_factorial_of_10() =
factorialScenario 10 3628800
|> Verify
If we run these scenarios with NUnit we will get the following output:
Scenario: When calculation factorial of 1
– Given 1
– When calculating factorial
=> It should equal 1
==> OK
==> Time: 0.0093s
Scenario: When calculation factorial of 10
– Given 10
– When calculating factorial
=> It should equal 3628800
==> OK
==> Time: 0.0018s
2. Using the ScenarioTemplate attribute
The second and shorter option is to use the ScenarioTemplate attribute, which is inherited from NUnit’s new TestCase attribute:
// with ScenarioTemplate Attribute
[<ScenarioTemplate(1, 1)>]
[<ScenarioTemplate(2, 2)>]
[<ScenarioTemplate(5, 120)>]
[<ScenarioTemplate(10, 3628800)>]
let When_calculating_fac_(x,result) =
Given x
|> When calculating factorial
|> It should equal result
|> Verify
This code will create 4 different scenarios, which NUnit will display and report separately:
3. Using ScenarioSource
The third option is to use the ScenarioSource attribute. Here we define a function which generates TestData:
/// with a scenario source
let MyTestCases =
TestWith 12 3 4
|> And 12 4 3
|> And 12 6 2
|> And 1200 40 30
|> And 0 0 0 |> ShouldFailWith (typeof<System.DivideByZeroException>)
And then we have to tell NaturalSpec which TestData a scenario should use:
[<Scenario>]
[<ScenarioSource "MyTestCases">]
let When_dividing a b result =
Given a
|> When dividing_by b
|> It should equal result
|> Verify
Summary
Sometime it makes sense to test a scenario with a bunch of different parameters. We can use the ScenarioTemplate attribute to easily parameterize our scenarios. If we want more flexibility we can use predefined scenarios with custom parameters or the ScenarioSource attribute.
Tags:
F#,
NaturalSpec,
nunit,
ScenarioTemplate,
TDD
In my last articles I gave an introduction in NaturalSpec, showed how to get started and demonstrated how we can use NaturalSpec to write automatically testable scenarios for C# projects. This time I will use the same “Car-Dealer”-sample to show how we can mock objects in NaturalSpec.
Mocking objects is an important technique in Test-driven development (TDD) and allows us to simulate complex behavior.
“If an object has any of the following characteristics, it may be useful to use a mock object in its place:
- supplies non-deterministic results (e.g. the current time or the current temperature);
- has states that are difficult to create or reproduce (e.g. a network error);
- is slow (e.g. a complete database, which would have to be initialized before the test);
- does not yet exist or may change behavior;
- would have to include information and methods exclusively for testing purposes (and not for its actual task).”
Wikipedia
In our sample we want to mock the Dealer.SellCar() functionality. The first step is to create an C#-Interface for the Dealer:
namespace CarSellingLib
{
public interface IDealer
{
Car SellCar(int amount);
}
}
NaturalSpec is using Rhino.Mocks as the underlying mocking framework, so we have to create a reference to Rhino.Mocks.dll in our spec library.
Now we can modify our spec to:
// 1. open module
module CarSpec
// 2. open NaturalSpec-Namespace
open NaturalSpec
// 3. open project namespace
open CarSellingLib
// define reusable values
let DreamCar = new Car(CarType.BMW, 200)
let LameCar = new Car(CarType.Fiat, 45)
// 4. define a mock object and give it a name
let Bert = mock<IDealer> "Bert"
// 5. create a method in BDD-style
let selling_a_car_for amount (dealer:IDealer) =
printMethod amount
dealer.SellCar amount
// 6. create a scenario
[<Scenario>]
let When_selling_a_car_for_30000_it_should_equal_the_DreamCar_mocked() =
As Bert
|> Mock Bert.SellCar 30000 DreamCar // 7. register mocked call
|> When selling_a_car_for 30000
|> It should equal DreamCar
|> It shouldn't equal LameCar
|> Verify
As you can see we changed part 4 (in order to get a mocked IDealer instead of the concrete Dealer). In part 7 we register our mocked behavior. We want that whenever Bert.SellCar is called with parameter 30000 the DreamCar should be returned.
The Verify-function checks if the mocked function has been called. If not the scenario will fail.
If we verify our spec with a NUnit runner we get the following output:
Scenario: When selling a car for 30000 it should equal the DreamCar mocked
– As Bert
– With Mocking
– When selling a car for 30000
=> It should equal BMW (200 HP)
=> It should not equal Fiat (45 HP)
==> OK
Tags:
F#,
Mocking,
NaturalSpec,
Rhino.Mocks
In my last two articles I gave an introduction in NaturalSpec and showed how to get started. This time I will show how we can use NaturalSpec to write automatically testable scenarios for C# projects.
Like the TDD principle “Write the tests first” we should write our spec first and use the “Red-Green-Refactor” method.
"Red" – Create a spec scenario that fails
At first I created a F# class library project called “Spec.CarSelling” and added project references to NaturalSpec.dll and nunit.framework.dll (see “Getting started” for further explanations).
Now I can write my first scenario:
// 1. define the module
module CarSpec
// 2. open the NaturalSpec namespace
open NaturalSpec
// 3. open project namespace
open CarSellingLib
// 4. define a test context
let Bert = new Dealer("Bert")
// 5. create a method in BDD-style
let selling_a_car_for amount (dealer:Dealer) =
printMethod amount
dealer.SellCar amount
// 6. create a scenario
[<Scenario>]
let When_selling_a_car_for_30000_it_should_equal_my_DreamCar() =
As Bert
|> When selling_a_car_for 30000
|> It should equal (new Car(CarType.BMW, 200))
|> Verify
At this stage the scenario is ready but doesn’t compile. This means we are ready with the "Red"-stage.
"Green" – Make the test the pass
In order to get the test green we have to create a C# class library called CarSellingLib and define the enum CarType and the classes Dealer and Car. Sticking to the YAGNI-principle we implement only the minimum to get the spec green (and ToString()-members for the output functionality).
namespace CarSellingLib
{
public enum CarType
{
BMW
}
}
namespace CarSellingLib
{
public class Car
{
public Car(CarType type, int horsePower)
{
Type = type;
HorsePower = horsePower;
}
public CarType Type { get; set; }
public int HorsePower { get; set; }
public override string ToString()
{
return string.Format("{0} ({1} HP)", Type, HorsePower);
}
public override bool Equals(object obj)
{
var y = obj as Car;
if(y == null) return false;
return Type == y.Type && HorsePower == y.HorsePower;
}
}
}
using System;
namespace CarSellingLib
{
public class Dealer
{
public Dealer(string name)
{
Name = name;
}
public string Name { get; set; }
public Car SellCar(int amount)
{
return new Car(CarType.BMW, 200);
}
public override string ToString()
{
return Name;
}
}
}
When we add a project reference to our spec-project the UnitTests should pass and we have completed the "Green" step. (See "Getting started" if you don’t know how to run the spec.) Now we can add some more scenarios to our spec:
// 1. define the module
module CarSpec
// 2. open NaturalSpec-Namespace
open NaturalSpec
// 3. open project namespace
open CarSellingLib
// 4. define a test context
let Bert = new Dealer("Bert")
// define reusable values
let DreamCar = new Car(CarType.BMW, 200)
let LameCar = new Car(CarType.Fiat, 45)
// 5. create a method in BDD-style
let selling_a_car_for amount (dealer:Dealer) =
printMethod amount
dealer.SellCar amount
// 6. create a scenario
[<Scenario>]
let When_selling_a_car_for_30000_it_should_equal_the_DreamCar() =
As Bert
|> When selling_a_car_for 30000
|> It should equal DreamCar
|> It shouldn't equal LameCar
|> Verify
[<Scenario>]
let When_selling_a_car_for_19000_it_should_equal_the_LameCar() =
As Bert
|> When selling_a_car_for 19000
|> It should equal LameCar
|> It shouldn't equal DreamCar
|> Verify
// create a scenario that expects an error
[<Scenario>]
[<Fails_with "Need more money">]
let When_selling_a_car_for_1000_it_should_fail_with_Need_More_Money() =
As Bert
|> When selling_a_car_for 1000
|> Verify
Now we are in the “Red”-Phase again.
"Refactor" – rearrange your code to eliminate duplication and follow patterns
After making the spec "Green" and doing some refactoring the project code could look like this:
namespace CarSellingLib
{
public enum CarType
{
Fiat,
BMW
}
}
namespace CarSellingLib
{
public class Car
{
public Car(CarType type, int horsePower)
{
Type = type;
HorsePower = horsePower;
}
public CarType Type { get; set; }
public int HorsePower { get; set; }
# region ToString, Equals
public override string ToString()
{
return string.Format("{0} ({1} HP)", Type, HorsePower);
}
public override bool Equals(object obj)
{
var y = obj as Car;
if(y == null) return false;
return Type == y.Type && HorsePower == y.HorsePower;
}
#endregion
}
}
using System;
namespace CarSellingLib
{
public class Dealer
{
public Dealer(string name)
{
Name = name;
}
public string Name { get; set; }
public Car SellCar(int amount)
{
if (amount > 20000)
return new Car(CarType.BMW, 200);
if (amount > 3000)
return new Car(CarType.Fiat, 45);
throw new Exception("Need more money");
}
public override string ToString()
{
return Name;
}
}
}
The spec output should look like the following:
Scenario: When selling a car for 1000 it should fail with Need More Money
– Should fail…
– As Bert
– When selling a car for 1000
Scenario: When selling a car for 19000 it should equal the LameCar
– As Bert
– When selling a car for 19000
=> It should equal Fiat (45 HP)
=> It should not equal BMW (200 HP)
==> OK
Scenario: When selling a car for 30000 it should equal my DreamCar
– As Bert
– When selling a car for 30000
=> It should equal BMW (200 HP)
==> OK
Scenario: When selling a car for 30000 it should equal the DreamCar
– As Bert
– When selling a car for 30000
=> It should equal BMW (200 HP)
=> It should not equal Fiat (45 HP)
>==> OK
4 passed, 0 failed, 0 skipped, took 1,81 seconds (NUnit 2.5).
Summary
I showed how we can use NaturalSpec for the Red-Green-Refactor process of C# projects and how easy it is to get a spec in natural language.
Tags:
.NET,
BDD,
F#,
NaturalSpec,
spec,
TDD
