Archive

Monthly Archives: November 2015

In today’s news, SDETs and software craftsman around the world have been leveraging test-mutation frameworks in retaliation for the relentless death marches and massive disappointments that many shops have been experiencing due to Dark-Matter Developers (aka: DMDs). Test-mutation frameworks are tools that are used to expose false-positives within a test automation suite. DMDs have been fudging code coverage reports with poor unit tests for decades. As a result, they have managed to control and stifle the software development industry. However, recently, Sleeper cells composed of disgruntled craftsman and SDETs have been activated from London to Miami, and from India to Brazil. As a result, code-reviews have erupted into screaming matches and mass firings, as DMDs now scramble to explain their misleading test coverage metrics and other exposed quality concerns. The software industry is now in complete disarray. Software user groups have been converted into Command and Control centers to further push DMDs to the edges of the IT industry by preaching test mutation frameworks to the masses.

Scott Nimrod, the self-professed emir of the revolution, released a statement to the press that read the following:

As the media scrambles to shed light on what I have been preaching for years, perhaps SDETs and craftsman around the world can join hands and finally seek comfort in recognizing that “for every end is a new beginning”.

 

Ten Commandments for Unit Testing

  1. Refactor SUT to limit LOC required to setup a unit test
  2. Limit a unit test to 10 LOC or less
  3. Engineer tests so that they fail because of business logic and not setup logic
  4. Test behaviors and NOT implementation details
  5. Unit test business logic and NOT integration concerns
  6. Control test dependencies before they control your tests
  7. Provide descriptive test names
  8. Test only one thing per unit test
  9. Engineer tests so that they’re self-contained and can run in complete isolation
  10. Investigate static classes when tests no longer run deterministically

Referenced: Testing with F#

Intro

Unit tests are essential for building software effectively. In addition, unit tests also enable developers to exterminate bugs quickly with extreme prejudice.

Protect this House from Bugs

I thought that I could use the video above as a metaphor so that I could hype-up my craftsman such as yourself into protecting your codebase with a defense-hungry mentality.

Now in a previous article, I provided a tutorial on how to implement MVVM using F# and WPF. However, in this article, I will provide an example of how to unit test a viewmodel.

ViewModel

Here’s a viewmodel:

namespace Model

    type ViewModel() =
        inherit ViewModelBase()

        let mutable firstName = "Scott"
        let mutable lastName = "Nimrod"

        member this.FirstName
            with get() = firstName 
            and set(value) = firstName <- value
                             base.NotifyPropertyChanged(<@ this.FirstName @>)
        member this.LastName
            with get() = lastName 
            and set(value) = lastName <- value
                             base.NotifyPropertyChanged(<@ this.LastName @>)

        member this.GetFullName() = 
            sprintf "%s %s" (this.FirstName) (this.LastName)

Now in order for us to unit test this viewmodel, we first need to employ some tools in order for us to perform this ceremony. I prefer to use FSUnit in conjunction with the NUnit framework. These two frameworks enable me to write some pretty concise and legible unit tests.

Perform the following steps:

  1. Download and install the NUnit extension from the NUnit website.
  2. Add a new F# library to your solution
FSharp_TestProject
3. On your test project, add the NuGet package, “FSUnit”.
FSUnit_Nuget

4. Add the reference, “NUnit.Framework” to your test project

NUnit_reference

Unit Test

Here’s a unit test:

module UnitTests
open Model
open FsUnit
open NUnit.Framework

[<Test>]
member __.``GetFullName = "Jon Doe" if FirstName = "Jon" and LastName = "Doh"``() =
    let vm = ViewModel()
    vm.FirstName <- "Jon"
    vm.LastName <- "Doe"

    Assert.AreEqual("Jon Doe", vm.GetFullName())

 

Conclusion

In conclusion, I just provided an example of how to unit test a viewmodel. Enjoy!

=)

Intro

I have reason to believe that F# will be the language of choice in several years for the .NET platform. This language was designed to assist error-prone developers such as myself from making mistakes that stem from having to write too many lines of code for expressing how a moderate operation is to execute. F# reduces the lines of code required by providing default constructs that supports cleaner and more concise code. As a result, in order to stay current, I have decided to go full throttle into learning this mysterious programming language.

The following tutorial details how to implement MVVM with F#.

Solution Explorer

To start off, let’s create two projects. Our first project will be a WPF project. Our other project will be a project to hold our viewmodel.

1. Create a WPF project.
2. Create a Portable Class Library

3. Add a ViewModelBase and a ViewModel file to the PCL (aka: Model)

NOTE:

The WPF project will contain our view and the PCL will contain our viewmodel.

Mine looks like the following (fully implemented):FSharpMVVM

ViewModelBase

We will first flush out our model project. To so, let’s first establish some reusable plumbing by establishing our base class for our deriving viewmodels to leverage.

The code below will provide our base behavior for sending a property change notification to an observer (i.e. a databound view):

namespace Model

open System.ComponentModel
open Microsoft.FSharp.Quotations.Patterns

type ViewModel () =
    let propertyChanged = 
        Event<PropertyChangedEventHandler,PropertyChangedEventArgs>()
    let getPropertyName = function 
        | PropertyGet(_,pi,_) -> pi.Name
        | _ -> invalidOp "Expecting property getter expression"
    interface INotifyPropertyChanged with
        [<CLIEvent>]
        member this.PropertyChanged = propertyChanged.Publish
    member private this.NotifyPropertyChanged propertyName = 
        propertyChanged.Trigger(this,PropertyChangedEventArgs(propertyName))
    member this.NotifyPropertyChanged quotation = 
        quotation |> getPropertyName |> this.NotifyPropertyChanged

Observe that the code above provides an interface which manages quotations so that a property name does not have to be hardcoded by hand. Hence this technique supports better maintainability in regards to future refactoring tools.

ViewModel

Now let’s implement our viewmodel. In our viewmodel, we will derive from our base class (i.e. ViewModelBase) to ensure that we trigger property change notification. Note that for our property setters we invoke the NotifyPropertyChange function on our base class. F# does not support the “protected” access modifier. As a result, we explicity call our base function and supply a refactor-friendly argument.

namespace Model
type ViewModel() =
    inherit ViewModel()
    let mutable firstName = ""
    let mutable lastName = ""

    member this.FirstName
        with get() = firstName 
        and set(value) =
            firstName <- value
            base.notifyPropertyChanged(<@ this.FirstName @>)

    member this.LastName
        with get() = lastName 
        and set(value) =
            lastName <- value
            base.notifyPropertyChanged(<@ this.LastName @>)

    member this.GetFullName() = 
        sprintf "%s %s" (this.FirstName) (this.LastName)

View

Let’s implement our view. In our view, we do NOT use a “class” attribute for our Window element. The class attribute supports code-behind ceremony that C# enables. Instead, for F# applications, we can just ensure that we do not include the class element. In addition, we add a TextBlock control and bind it to a property on our viewmodel.

<Window
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:model="clr-namespace:Model;assembly=Model"
mc:Ignorable="d"
Title="MainWindow" Height="350" Width="525">

<Window.DataContext>
<model:ViewModel />
</Window.DataContext>

<Grid>
<TextBlock Text="{Binding FirstName}" />
</Grid>
</Window>

When and if you wire this up correctly and run the application, you should end up with the following results:

FSharpMVVM._Runtime

Conclusion

In conclusion, I have reason to believe that F# will be the language of choice in several years for the .NET platform. This language was designed to assist error-prone developers such as myself from making mistakes that stem from having to write too many lines of code for expressing how a moderate operation is to execute. F# reduces the lines of code required by providing default constructs that supports cleaner and more concise code. As a result, in order to stay current, I have decided to go full throttle into learning this mysterious programming language and provided a tutorial to get readers up and running.

It’s approximately four O’clock in the morning in Cleveland, Ohio. My soul rises from my sleeping body and nudges me to wake up. Like Terminator, my body’s still at rest, but my eyelids lift abruptly. Analogous to clock-work, the program that I call my daily routine has just been activated.

I reach for my phone and begin my morning routine of surfing YouTube for another interesting topic for my mind to absorb. I declared a couple weeks ago that I would pick up F# as my next programming language. So I look for F# related topics. However, I soon realized that I’ve already consumed the majority of the videos pertaining to this language. I then scroll down the list of search results and immediately recognize a familiar face. But I noticed that this face is not even related to F#. Instead it’s one of my favorite thought leaders. It’s David Heinemeier Hansson (aka: DHH). The topic of the video he’s featured on is titled “Unlearn your MBA”.

I listened to the video and thoroughly enjoyed his presentation. But one thing really stuck out in the video that I found was very peculiar. At one point in the video, he mentioned that every college graduate that’s eager to join the workforce should work at a really bad company. His argument was that there’s so much to learn from people that are horrible at running a business or in my case, building software, that when we are ready to go full throttle into our career, we can do so off of the lessons learned from people that are bad at their jobs.

That video that I watched and that message that he relayed really made me think about a recent experience that I had in Miami. I was so disappointed with a shop that I was working with that I could no longer deliver value to their business based on my standards of professionalism. I just could not understand why senior developers at that shop were so adamant on building software without any type of controls in place to notify them of quality concerns.

Their last project was a complete failure. It was essentially a death march where the developers had to work mandatory weekends to drive down the bug count. Each time they would fix one bug, two more bugs would surface. Of course, this team downright refused to leverage unit tests as a quality control to assist them with their bug fixes. Thus, as you might’ve guessed, they programmed blindfolded. In addition, the team lead did not feel the need to include QA at the beginning of the project. In fact, QA didn’t touch the product until the development team declared software construction completed. And as you’ve might have guessed, the software reeked with bugs. Of course, the majority of these bugs could have been identified and exterminated early within the development phase if QA would’ve just ran in parallel with code construction. However, that idea was downright crazy-talk. The end result was this. The project failed and it failed miserably. But saying the project failed miserably is an understatement. This project was nothing short of an atrocity that destroyed trust and killed morale. The project lead quit and was soon followed by several more resignations from other developers on the project. Meanwhile, I observed all of this my first month on assignment and was deeply concerned about what I was getting myself into.

I now look at my software development skills as one of my businesses. Therefore, I must protect the reputation of my business at all cost. When I’m building software for a client, it must be in the act of continuous competence without conveying any negligence. And yet, that shop that I attempted to help wanted me to follow their framework which inevitably led to pain, suffering, and mass abandonment.

David Heinemeier Hansson was right. If it were not for that specific experience of working with poor developers, I probably would not have wrote the thought provoking article “Are you a Professional Debuggerer”. In addition, I probably would not have got on DotNetRocks.com or DeveloperOnFire.com. As a result, perhaps we should all target a really bad company to work for so that we can really experience the ramifications of bad business and development practices while we are still at the beginning of our career. Once we can actually experience this pain firsthand, then I think we can finally appreciate businesses that really do strive for continuous improvement and thus continue to push our industry in a forward direction versus in endless circles. In doing that, perhaps then we can seek comfort in recognizing that for every end is a new beginning.

I recently did a podcast with David Rael on his show Developer on Fire. While on his show, he asked me a question regarding my professional persona. I responded to his question by stating that every single morning that I wake up, I can’t help but wonder if I’m really a software craftsman. Hence, I have reason to believe that I may have more in common with the Prima Donna.

The episode that I’m on will air sometime next week. But until it does, I have some questions for the viewers of this blog:

  • What really is a Prima Donna?
  • Can a developer be both a Prima Donna and a Software Craftsman?
  • What really is the difference between the two?
  • Do software craftsman typically evolve (or devolve) into Prima Donnas?

Please provide your thoughts on the comment section below:

Did you know that you can leverage Code Snippets in F#?

FSharp_CodeSnippet_Editor

Big shoutout to Tao Liu for providing this support.

Here’s a summary of how to leverage this awesome productivity tool:

  1. Download the F# Snippets Extension.
  2. Download the code snippet files here.
  3. Select Tools | Code Snippets Manager.
  4. Ensure the following path exists:C:\Users\<username>\Documents\Visual Studio 2015\Code Snippets\Visual F#\My Code Snippets

NOTE:

You should observe something like this once configured:

CodeSnippetManager5. Copy the code snippet files to the path above.

i.e. C:\Users\<username>\Documents\Visual Studio 2015\Code Snippets\Visual F#\My Code Snippets

6. Launch Visual Studio

7. Invoke Code Snippets window with the following keys:Ctrl K+X

8. Observe code snippet items.

FSharp_CodeSnippet_Editor