• louis vuitton outlet
  • nike air max
  • ray ban uk
  • oakley sunglasses outlet
  • cheap jordan shoes
  • toms outlet
  • Cheap Oakleys Sunglasses
  • fifa coins
  • ray ban
  • cheap uggs
  • ray ban uk
  • nike air max
  • ray ban outlet
  • burberry uk
  • fut coins
  • fut 14 coins
  • fut coins
  • Christian Louboutin Outlet
  • michael kors outlet
  • coach outlet
  • louis vuitton outlet
  • fifa coins
  • ray ban
  • Custom iphone cases
  • nike
  • monster beats
  • nike outlet
  • Christian Louboutin Outlet
  • burberry outlet
  • coach outlet
  • iphone cases
  • LV
  • new balance
  • 2012 January

    A couple of weeks ago, I announced a CoffeeScript/JavaScript assertion library called ExpectThat. In this post, I’ll provide a more real-world example of how ExpectThat can be used. For this example, I’ll be using the jQuery plugin and tests from one of Josh Bush’s posts entitled “Testing jQuery Plugins with Node.js and Jasmine“.

    The jQuery plugin

    The code that follows is a re-write (in CoffeeScript) of the simple jQuery plugin that Josh provided in his post.

    # Ported from Josh Bush's example at http://digitalbush.com/2011/03/29/testing-jquery-plugins-with-node-js-and-jasmine/
    $ = jQuery
    $.fn.placeholder = (description) ->
      @.each ->
        input = $(@)
        # Note: We should use "on" instead of "bind" with the latest version of jQuery, but 
        # we'll leave this just like the original for now.
        input.bind("blur.placeholder", -> input.val(input.val() or description))
          .bind("focus.placeholder", -> if input.val() is description then input.val(''))
          .trigger "blur.placeholder"

    This jQuery plugin provides a basic watermark type of feature for an input box.

    The specs

    Since Josh has already done the work of writing the specs for this jQuery plugin, all that I need to do is port this to CoffeeScript and add in ExpectThat. To mix things up a bit, I’ve chosen to use Mocha instead of Jasmine (though ExpectThat works just as well for Jasmine). For simplicity, I’ve combined the spec files from Josh’s post.

    # Ported from Josh Bush's example at http://digitalbush.com/2011/03/29/testing-jquery-plugins-with-node-js-and-jasmine/
    
    describe "Given a jquery.placeholder with", ->
      input = undefined
      describe "no value", ->
        before -> input = $("<input />").appendTo("body").placeholder "foo"
    
        describe "when calling placeholder plugin", ->
          expectThat -> input.val().should equal "foo"
    
        describe "when focusing input without user value", ->
          before -> input.focus()
          expectThat -> input.val().should equal ""
    
        describe "when leaving input without user value", ->
          before -> input.focus().blur()
          expectThat -> input.val().should equal "foo"
    
      describe "a user supplied value", ->
        before -> input = $("<input />").appendTo("body").val("bacon").placeholder "foo"
    
        describe "when calling placeholder plugin", ->
          expectThat -> input.val().should equal "bacon"
    
        describe "when focusing input with user value", ->
          before -> input.focus()
          expectThat -> input.val().should equal "bacon"
    
        describe "when leaving input without user value", ->
          before -> input.focus().blur()
          expectThat -> input.val().should equal "bacon"

    Apples to apples

    Here’s a quick before and after comparison (with both examples in CoffeeScript):

    Before ExpectThat:

        describe "when calling placeholder plugin", ->
          it "should show placeholder value", ->
            expect(input.val()).toEqual("foo")

    After ExpectThat:

        describe "when calling placeholder plugin", ->
          expectThat -> input.val().should equal "foo"

    Josh’s tests are already very readable, but by adding ExpectThat, I’m able to eliminate 1 line from every test and allow each to be self-documenting.

    An example of the result of running the specs in the browser is shown below:

    Wait, what about Node?

    “So”, you say, “this is great, but Josh’s post was all about using the same code and specs from the browser in Node.js”. Ah, yes, thanks for reminding me. It’s pretty simple to run these same tests in Node. Here are the steps:

    1. Use NPM to install mocha at a global level (i.e. npm install mocha -g) then install jsdom, jquery, and expectThat.mocha at the local level (i.e. npm install <package name>).

    2. Create a file called runspecs.coffee with the code shown below and compile it however you choose (i.e. “coffee –compile –output lib/ specs/” Note: though it doesn’t look like it, there are 2 dashes before compile and output.).

    window = require("jsdom").jsdom().createWindow()
    jQuery = require("jquery")
    require("expectThat.mocha")
    require("./jquery.placeholder.js")
    require("./jquery.placeholder.spec.js")

    3. Run the tests with a command such as “mocha ‘lib/runspecs.js’ –reporter spec” (note: though it doesn’t look like it, there are 2 dashes before reporter.) and you should see something like the following:

    In future posts, I’ll show how to do similar testing with other tools such as Jasmine-Node and Zombie.js. To learn more about ExpectThat, get involved, and/or keep an eye on its progress, go to https://github.com/dmohl/expectThat.

    Tagged with:  

    About a month ago, I announced that most of the existing F# project templates on Visual Studio Gallery had been updated to include support for Visual Studio 11. In that post, I mentioned some new item templates that had been included in the update to the F# XAML Item Templates extension. This post provides a bit more information related to that update.

    The F# XAML Item Templates extension was designed to make working with F# + WPF and Silverlight a little eaiser. I provided a brief overview of these features back in June. However, Windows Phone XAML related development was still lacking. The previous approach to adding XAML files was to either create a blank file, change the extension, and manually add the appropriate starting XAML or create the XAML from one of the C# item templates, remove the code-behind files, and tweak the resulting XAML. While neither of these options is extremely time consuming, it can quickly become annoying.

    The latest update to this Visual Studio extension reduces this annoyance by providing F# Windows Phone 7 XAML item templates. Once this VSIX is installed, you can add a Windows Phone 7 XAML file by doing the following:

    1. In a Windows Phone F# project, proceed with adding a new item as you normally would (i.e. Ctrl+Shift+A).

    2. The resulting wizard (shown below) includes several new item templates starting with “F#…” that match the C# versions, but that do not generate C# code-behind files. 

    While you still have to write the small amount of F# code to wire this up, it makes life a little bit easier.

    Tagged with:  

    I’m a big fan of automated testing. In fact, on the rare occasions that I don’t write tests, I find that I can’t shake the thought that something has been missed.

    As with all aspects of my coding efforts, I am constantly looking for ways to improve the process, make tests more readable, and reduce room for error. With these goals in mind, I’d like to introduce ExpectThat.

    What is ExpectThat?

    ExpectThat is an expressive, self-documenting, assertion library for CoffeeScript, that seeks to improve testing efforts with your favorite testing framework. It does this by providing a syntax similar to FsUnit (a library for F#) that makes assertions more readable and then automatically translates that readable code into descriptive test output. This ensures that your test names always stay in sync with your tests and allows your code to speak for itself. ExpectThat currently supports Pavlov, QUnit, and Jasmine. Overtime, support for additional testing frameworks will be added.

    Let’s See it in Action

    The following example shows how to write tests with ExpectThat for Pavlov in CoffeeScript:

    pavlov.specify "Example Specifications", ->
        foo = "bar"
        describe "When testing 'should equal'", ->
            expectThat -> foo.should equal "bar"
        describe "When testing 'shouldnt equal'", ->
            expectThat -> foo.shouldnt equal "baz"
        describe "When testing for 'true'", ->
            expectThat -> (foo is "bar").should be true
            expectThat -> (foo is "baz").shouldnt be true
        describe "When testing for 'false'", ->
            expectThat -> (foo is "baz").should be false
            expectThat -> (foo is "bar").shouldnt be false
        describe "When testing 'greater than'", ->
            expectThat -> (9.1).should be greaterThan 9
            expectThat -> (9.1).shouldnt be greaterThan 10
            expectThat -> 10.shouldnt be greaterThan 10

    Here’s a screenshot of the result:

    Other Testing Frameworks

    As I mentioned, ExpectThat currently supports QUnit and Jasmine in addition to Pavlov. The following are examples for each of these.

    QUnit:

    module "Example QUnit Specifications"
    
    foo = "bar"
    
    module "When testing should equal"
    
    expectThat -> foo.should equal "bar"
    
    module "When testing shouldnt equal"
    
    expectThat -> foo.shouldnt equal "baz"
    
    module "When testing for true"
    
    expectThat -> (foo is "bar").should be true
    expectThat -> (foo is "baz").shouldnt be true
    
    module "When testing for false"
    
    expectThat -> (foo is "baz").should be false
    expectThat -> (foo is "bar").shouldnt be false

    Jasmine:

    describe "Example Jasmine Specifications", ->
        foo = "bar"
        describe "When testing should equal", ->
            expectThat -> foo.should equal "bar"
        describe "When testing shouldnt equal", ->
            expectThat -> foo.shouldnt equal "baz"
        describe "When testing for throw", ->
            expectThat -> (-> throw "test exception").should throwException
            expectThat -> (-> throw "test exception").should throwException "test exception"
        describe "When testing for less than", ->
            expectThat -> 10.should be lessThan 11
            expectThat -> (10.1).shouldnt be lessThan 10

    Getting Started with ExpectThat

    There are a couple of ways to get started with ExpectThat. First, head over to the ExpectThat GitHub site and browse through the documentation. You can then clone the repo and grab any of the examples from the example folder. If you are writing an ASP.NET app in Visual Studio, another option is to install one of the available NuGet packages.

    Available Assertions

    ExpectThat currently provides the following assertions:

    - equal
    - stictlyEqual
    - false
    - true
    - greaterThan
    - greaterThanOrEqual
    - lessThan
    - lessThanOrEqual
    - throwException
    - ‘to’ and ‘be’ can be used in most cases to make tests more readable.

    In addition to the out-of-the-box assertions, ExpectThat allows for the creation of custom assertions. Examples of this for each of the supported testing frameworks are available in the example folder on GitHub.

    ExpectThat in JavaScript

    While the syntax of ExpectThat works best with CoffeeScript, you can certainly use it in JavaScript as well. Simply add in the missing braces, parens, semi-colons, function keywords, etc. The following provides a simple example for Pavlov:

    pavlov.specify("expectThat Specifications", function() {
        describe("When testing should equal", function() {
            var foo = "bar";
            expectThat(function() {
                foo.should(equal("bar"));
            });
            expectThat(function() {
                (foo + "test").should(equal("bartest"));
            });
        });
    });

    Getting Involved

    There are a lot of things left to do for ExpectThat and I’d love to hear your thoughts on direction, enhancements, etc. as well as have any help that anyone would like to offer. If you want to get involved, fork me on GitHub.

    Tagged with:  

    Announcing FsUnit 1.0

    On January 3, 2012, in Uncategorized, by Dan Mohl

    A couple of weeks ago I announced a few enhancements to FsUnit. Today, I’m proud to announce the release of FsUnit 1.0. Version 1.0 includes support for additional testing frameworks, a new assertion function, and more…

    New Testing Framework Support:

    All previous releases of FsUnit provided support for only NUnit; however, the goal for FsUnit has always been to provide support for other major testing frameworks as well. This release largely accomplishes this goal by adding support for MbUnit version 3.3.454.0 and xUnit.NET version 1.8.0.1549. While the majority of functions provided for NUnit are also provided for these two testing frameworks, there are a couple of features that are not available. Each of these missing features can easily be worked around and the FsUnit unit tests provide examples of this.

    NuGet Packages:

    The easiest way to get started with FsUnit is to install one of the following NuGet packages.

    - FsUnit for NUnit can be installed via the original NuGet package ID of FsUnit.

    - FsUnit for xUnit.NET can be installed via the FsUnit.xUnit package ID.

    - FsUnit for MbUnit can be installed via the FsUnit.MbUnit package ID.

    Additional Assertion:

    In addition to support for MbUnit and xUnit.NET, the equalWithin function has been added. Thanks to erdoll for requesting this enhancement and for providing much of the code for the NUnit implementation. The equalWithin function allows an equality assertion with a specified tolerance. Examples are provided below:

    NUnit Example:

    module Test.``equalWithin assertions``
    
    open NUnit.Framework
    open FsUnit
    
    [<Test>]
    let ``should equal within tolerance when less than``() =
        10.09 |> should (equalWithin 0.1) 10.11
    
    [<Test>]
    let ``should not equal within tolerance``() =
        10.1 |> should not ((equalWithin 0.001) 10.11)

    xUnit.NET Example:

    module Test.``equalWithin assertions``
    
    open Xunit
    open FsUnit.Xunit
    
    [<Fact>]
    let ``should equal within tolerance when less than``() =
        10.09 |> should (equalWithin 0.1) 10.11
    
    [<Fact>]
    let ``should not equal within tolerance``() =
        10.1 |> should not ((equalWithin 0.001) 10.11)

    MbUnit Example:

    module Test.``equalWithin assertions``
    
    open MbUnit.Framework
    open FsUnit.MbUnit
    
    [<Test>]
    let ``should equal within tolerance when less than``() =
        10.09 |> should (equalWithin 0.1) 10.11
    
    [<Test>]
    let ``should not equal within tolerance``() =
        10.1 |> should not ((equalWithin 0.001) 10.11)

    Now on GitHub:

    Last but not least, an FsUnit GitHub site is now available at https://github.com/dmohl/FsUnit. FsUnit has had several contributors with submissions ranging from inception and NUnit implementation (by Ray Vernagus), to major and minor enhancements, to examples and documentation. I hope that this move to GitHub will spur additional collaboration. The GitHub site will now act as the primary place for development and collaboration, while the CodePlex site will house major releases. We would love to have additional features and contributors, so jump on over and submit a pull request.

    On to the Next One…

    We are already working on the next release of FsUnit. Rodrigo Vidal has submitted a few new NUnit assertions–which will be ported to the MbUnit and xUnit.NET implementations where possible. Additionally, there have been discussions of pulling in Phillip Trelford‘s F# friendly Mocking library.

    Where would you like to see FsUnit go? We’d love to hear from you!

    Tagged with: