You can get the new bits from CodePlex, NuGet or go to the Visual Studio Gallery to get the updated Visual Studio Context Menu Extension  and Unit Test Explorer adapter for Visual Studio 2012.

Changes and Fixes

• Added Code Coverage support (item 113)
• Updated versions of QUnit(v1.11.0), TypeScript(v0.8.3) and CoffeeScript(v1.6.2)
• jasmin-jQuery toContain tests fail with reason “Passed.” (item 95)
• FileSearchLimit=300 cancels test run with more than 300 tests (item 89)
• /failOnScriptError exits with 1 even when there are not errors (item 97)
• ‘undefined’ is not a function after updating to 2.3 (item 96)
• No tests found when using QUnit.test instead of test (item 94)
• Allow including files without building them (item 93)
• Improve “/openInBrowser” (item 91)
• Add TestFileTimeout setting to chutzpah.json (item 110)
• Need a later version of phantom bundled with Chutzpah (item 107)
• QUnit test runner module gotcha in 2.3 (item 109)
• Support for unicode (item 111)
• Improve CoffeeScript parse error reporting (item 80)

Code Coverage

Chutzpah’s new code coverage features is built on top of the great open source library Blanket.js. When you run with code coverage enabled it will use Blanket.js to instrument the files under test and gather the coverage results. You can perform code coverage from the command line and both Visual Studio plugins.

Command Line

To get code coverage from the command line you pass the /coverage flag to chutzpah.console.exe.

chutzpah.console.exe /coverage /path test.js

After this command finishes you will have a two files placed in your current directory

_Chutzpah.coverage.html – The rendered html results
_Chutzpah.coverage.json – The raw json results

When you open the results html file you will see something like:

Visual Studio Context Menu Extension

The Visual Studio Context Menu Extension now contains a Show Code Coverage command which will perform code coverage and open the results in a browser.

Visual Studio 2012 Test Adapter Extension

For the Unit Test Explorer adapter for Visual Studio 2012 Chutzpah piggybacks on the existing “Analyze Code Coverage” menu option and uses it to run with code coverage and show the results in a browser. Ideally, Chutzpah would integrate into the code coverage reporting built into VS but I was unable to figure out a good way to plug in to that. The side effect is that when you run this command VS will open their results window first (with nothing in it) and then Chutzpah will launch its results in a browser.

NOTE: I have noticed some performance issues when running “Analyze Code Coverage for All Tests” command. I think it might be VS doing extra work for no reason since it is trying to generate its own report.

Configuration Code Coverage

Being able to run code coverage is not enough since in many cases the results will not be accurate. For example, if your project uses jQuery you do not expect your test to cover all the lines of jQuery’s source code (that would be one impressive test). Therefore you need to exclude files/directories from participating in code coverage. There are two way you can do that with Chutpah: command line arguments or a chutzpah.json file.

If you are running Chutzpah from the command line there are two additional arguments you can pass coverageIncludes and  coverageExcludes. These are a comma separated list of files/paths you want to include or exclude from coverage. They can use a glob format where * matches zero or more characters and ? matches one character. For example:

Exclude files that ends in matt.js

chutzpah.console.exe /path test.js /coverage /coverageExcludes *matt.js

Include only dog.js and any file with a single character extension

chutzpah.console.exe /path test.js /coverage /coverageIncludes "*\dog.js, *.?"

Include *query.js but exclude jQuery.js

chutzpah.console.exe /path test.js /coverage /coverageIncludes *query.js /coverageExcludes *\jquery.js

The other option for configuring code coverage is the chutzpah.json file. There are two new setting which you can use CodeCoverageExcludes and CodeCoverageIncludes. These settings work in the same way as the their command line counterpart. The main difference is that you must escape backslashes.

{
  "CodeCoverageExcludes": ["*\\jquery.js"],
  "CodeCoverageIncludes": ["*query.js", "*\\dog.js"]
}

Test timeout setting

Chutzpah already has a test timeout setting but you previously could only configure it from the command line or with a setting in VS. This was inflexible especially if you want a different timeout for different tests. To solve this Chutzpah now include a TestFileTimeout setting in the chutzpah.json file. For example if you want a 10 second time out for a certain directory just place a chutpah.json file with the following in it:

{
    "TestFileTimeout": "10000"
}

Chutzpah Specific Reference

With the addition of TypeScript support a few releases ago several people reported issues when using Chutzpah with the TypeScript plugin in VS. The problem occurs since both TypeScript and Chutzpah are using the <reference path…> comments for different purposes. To get around this issue Chutzpah now supports two ways to reference dependent files.

1. The existing general way

/// <reference path="foo.js" />

2. The new Chutzpah specific way

/// <chutzpah_reference path="foo.js" />

Using the latter will let Chutzpah know about your dependency graph and should not confuse the TypeScript compiler.

Excluding References

The reference syntax is also used by VS to give intellisense in JS files. This leads to an issue since sometimes you may reference a version of a file just for intellisense but you do not want Chutzpah to copy it. In this case you now can include the chutzpah-exclude attribute to have it ignored by Chutzpah:

/// <reference path="someDependency.js" chutzpah-exclude="true" />

Running against a remote url

Chutzpah now supports executing a remote test harness. If you have a html test file on a remote server (like http://somesite.com/test.html) you can tell Chutzpah to execute that file directly

chutzpah.console.exe http://somesite.com/test.html

Note: Chutzpah does not support running anything but .html files remotely. If you want to run Chutzpah directly on a .js, .ts or .coffee file they must be local on disk.

1. All SignalR requests fail to use the more efficient transports (ServerSentEvents/ForeverFrame) and fall back to using Long Polling

2. Some messages get replayed multiple times in IE9

After looking into the issue for a while we figured out it was caused by a setting in ARR called Response Buffer Threshold.

Response buffer threshold (KB)

Lists the size of the buffer, in kilobytes, that ARR uses to retain a response before sending it to the client. Content that is smaller in size than the threshold can be cached.

By default this is set to 256kb which means that it will buffer responses until they reach that amount. By setting this to 0 ARR will no longer buffer and SignlR will function correctly.

You can get the new bits from CodePlex, NuGet or go to the Visual Studio Gallery to get the updated Visual Studio Context Menu Extension  and Unit Test Explorer adapter for Visual Studio 2012.

Changes and Fixes

• Added Chutzpah.json settings file support
• Consistent conversion error (item 70)
• System.IO.IOException: The handle is invalid when running from inside WebStorm (item 77)
• Exception has been thrown by the target of an invocation. inside Visual Studio 2012 (item 65)
• Tests are hanging (ChutzpahTimeoutException) (item 72)
• Reference root path should be project (item 83)
• Smarter coffeescript compilation (item 75)
• Running with parallelism gives faulty timing (item 81)
• Running with parallelism gives System.IO.IOException (item 74)
• Compile all TypeScript files at the same time (item 82)

The Chutzpah Settings File

The Chutzpah settings file is an .json file that you can place anywhere in your testing directories to inform Chutzpah of test specific settings. The Chuzpah settings file is completely optional and if the file or any of its properties are omitted Chutzpah will use the default values.

When Chutzpah is run on a file (lets say test.js) it scans the current directory for a file named chutzpah.json. If it does not find one it will recursively traverse up the directory chain looking for one. This behavior provides a lot of flexibility since you can provide multiple chutzpah.json files in your tree and each one will work over its sub-folder. This lets you have different settings for different groups of tests.

Chutzpah.json Format

The settings file is a text file with json content of the following format:

{
    "Framework": "qunit|jasmine",

    "TestHarnessLocationMode": "TestFileAdjacent|SettingsFileAdjacent|Custom",

    "TestHarnessDirectory": "<Path to a folder>",

    "TypeScriptCodeGenTarget" : "ES3|ES5",

    "RootReferencePathMode":"DriveRoot|SettingsFileDirectory"
}

The chutzpah.json file supports the following properties

Framework – Determines what testing framework to use. This will override the other detection methods. This is helpful if Chutzpah is having trouble figuring out what your intended framework is. If left out Chutzpah will automatically try to detect the framework.

TestHarnessLocationMode – Determines where to place the generated html test harness files. The default mode is TestFileAdjacent which means the harness is placed in the same directory as the test file. SettingsFileAdjacent means it is placed in the same directory as the chutzpah.json file. Custom mode lets you specify a custom path to the directory.

TestHarnessDirectory – When TestHarnessLocationMode is set to Custom this is either the relative or absolute path to the directory where to place the test harness.

TypeScriptCodeGenTarget – When running on a TypeScript file this property will tell the TypeScript compiler what type of code to generate. ES3 is for ECMAScript 3 and ES5 is for ECMAScript 5.

RootReferencePathMode – This property determines what directory a rooted reference path refers to. In a test file Chutzpah parses the <reference path=”" /> tags to determine your test dependencies. By default  (the DriveRoot setting) if you write <reference path=”\a.js” /> Chutzpah will look for a.js under C:\ (assuming you are running your test in the C drive). However, if you set this property to SettingsFileDirectory Chutpah will now look for a.js relative to the location of the chutzpah.json file. This is useful if you have a large project and want to minimize the number of long reference paths.

Examples:

This file tells Chutzpah to use QUnit and to place the test harness next to the chutzpah.json file:

{
    "Framework": "qunit",
    "TestHarnessLocationMode": "SettingsFileAdjacent"
}

This file tells Chutzpah to convert TypeScript to ES5 code and to place the test harness in a custom directory:

{
    "TypeScriptCodeGenTarget" : "ES5",
    "TestHarnessLocationMode": "Custom",
    "TestHarnessDirectory": "../Some/Folder"
}

Changes

• Added support for writing tests in TypeScript (item 67) 
• Fixed encoding problem with .coffee files (item 63)
• Allow reference paths for folders (item 68)
• Some Unit Test Explorer bug fixes
• Added clearer error messages when test file does not exist

TypeScript Support

Chutzpah now supports running unit tests you write in TypeScript. Chutzpah will automatically generate temporary JavaScript files for your referenced TypeScript files and use those to gather the test results.
For example given a TypeScript test file that references another TypeScript file:

/// <reference path="../code/code.ts" />

test("will add 5 to number", function () {
    var res:number = mathLib.add5(10);

    equal(res, 15, "should add 5");
});

It will parse that file as well as the referenced code.ts files and generate corresponding .js files.

If you are writing QUnit tests be aware that you need to write QUnit.module instead of just module since module is a reserved word in TypeScript.

Referencing Folders

In your test files you can now reference folders using the reference declarations. For example when Chutzpah sees this line:

/// <reference path="../someFolder/" />

It will traverse that folder and add the files in it as references. This can be easier to manage than referencing many files individually.

> cd ../

Now that may not look like a lot of characters but it gets worse when I want to jump 3 or 4 levels up:

> cd ../../../../

Annoying! To fix this I added this little snippet to my PowerShell profile:

for($i = 1; $i -le 5; $i++){
  $u =  "".PadLeft($i,"u")
  $unum =  "u$i"
  $d =  $u.Replace("u","../")
  Invoke-Expression "function $u { push-location $d }"
  Invoke-Expression "function $unum { push-location $d }"
}

This beautiful bit of code generates two sets of functions. One lets me move up a directory a given number of times by running a command like:

> u4

This will move up four directories. The second set of functions does the same thing but by typing u the number of times you want to traverse up:

> uuuu

Now I can hear you saying “Hey Matt, You claim to be all about being fast from the command line so why would you ever run the command uuuu when you can just run u4?”

That is an astute observation nameless reader! But sometimes I am in a mood where it is satisfying to press one key repeatedly. Ok?

Changes

• Added support for writing tests in coffee script (item 58)  – More details below
• Added option to ouput test results to XML file (item 57)
• Changed chutzpah.console.exe output to support VS error list integration (item 48)
• Tests complete doesn’t match total when using parallelism (item 59)

More about CoffeeScript Support

Chutzpah now supports running unit tests you write in the CoffeeScript language. Chutzpah will automatically generate temporary JavaScript files for your referenced CoffeeScript files and use those to gather the test results.
For example given a CoffeeScript test file that references another CoffeeScript file:

## <reference path="../code/code.coffee" />

test "A basic test", ->
  ok true, "this test is fine"
  value = "hello"
  equal "hello", value, "We expect value to be hello"

It will parse that file as well as the referenced code.coffee file and generate corresponding .js files. Notice the syntax for referencing other files. For CoffeeScript files Chutzpah uses comments that start with ## to indicate a reference declaration.

Notable Changes

Streaming of test results

The previous version of Chutzpah would only report test results after the whole test file was finished. Version 2.0 re-architects how Chutzpah communicates with PhantomJS to stream the results in real-time. This change leads to a much more responsive test running experience. The streaming change enabled the addition of the TestStart, FileLog and FileError methods to the execution callback interfaces.

public interface ITestMethodRunnerCallback
{
  void TestSuiteStarted();
  void TestSuiteFinished(TestCaseSummary testResultsSummary);
  void FileStarted(string fileName);
  void FileFinished(string fileName, TestCaseSummary testResultsSummary);
  void TestStarted(TestCase testCase);
  void TestFinished(TestCase testCase);
  void ExceptionThrown(Exception exception, string fileName);
  void FileError(TestError error);
  void FileLog(TestLog log);
}

HTML Test Files are run in place

When running Chutzpah on an existing HTML test harness it will no longer parse this file and generate its own test harness in the temp directory. Chutzpah now trusts the HTML test harness you give it and will just run the file. This will help support many of the fringe scenarios that were not supported well before. For JavaScript files Chutzpah will still generate its own test harness.

Parallel Test File Execution

You can now specify through both the command line and through a Visual Studio options page a level of parallelism for Chutzpah. By default this is 1 but if you have a large number of test files putting a larger number results in a significant performance increase.

From the command line the new argument is

 /parallelism n           : Max degree of parallelism for Chutzpah. (Defaults to 1)

In Visual Studio you can set this in the existing options page for the context menu extension and in the new options page for the Unit Test Explorer adapter:

Testing Mode Drop Down

In the screenshot above you may have noticed the Testing Mode option. This is a new configuration option for the Chutzpah test adapter. This lets you choose whether Chutzpah will scan and run HTML files, JS files or both.

Improved RequireJS support

I will write a full post to go into more detail about this but Chutzpah is now able to run tests that are using RequireJS. This support isn’t perfect and you may need to tweak your RequireJS testing setup to make it work. There are a couple examples checked in which demonstrate this functionality. For an HTML test file see here and for running a JS file directly see here.
 

Upgraded versions of Jasmine and QUnit

When generating its own test harness Chutzpah will now use QUnit 1.9 and Jasmine 1.2

And as always if you have any ideas/bugs/suggestions or you want to contribute code please check out the Chutzpah CodePlex page.

C++ users rejoice!

Coinciding with the release Visual Studio 2012 RC, I pushed an update of the Chutzpah test adapter for the Unit Test Explorer (UTE). I increased performance of the adapter through better caching and the new UTE notification feature which lets a test adapter notify the UTE when a test has changed.  With these changes, the Chutzpah adapter is a strong example of a file based test adapter.

The Chutzpah test adapter revolves around four interfaces:

1. ITestContainer – Represents a file that contains tests
2. ITestContainerDiscoverer – Finds all files that contain tests
3. ITestDiscoverer – Finds all tests within a test container
4. ITestExecutor – Runs the tests found inside the test container

This post will cover each of these interfaces, show Chutzpah’s implementations and describe how to debug test adapters.

ITestContainer

A test container is an object that contains tests (shocking right?). You can have a test container represent a file, folder, a dll or anything else.  For Chutzpah a test container represents a JavaScript test file.  The interface for a test container contains several members:

public interface ITestContainer
{
  ITestContainerDiscoverer Discoverer { get; }
  string Source { get; }
  int CompareTo(ITestContainer other);
  ITestContainer Snapshot();
  IEnumerable<Guid> DebugEngines { get; }
  FrameworkVersion TargetFramework { get; }
  Architecture TargetPlatform { get; }
  bool IsAppContainerTestContainer { get; }
  IDeploymentData DeployAppContainer();
}

but the most important are:

• Discoverer – An instance of a test container discoverer, this is covered this in the next section.
• Source – A string that identifies this test container. For Chutzpah this is the file path.
• CompareTo – Compares two test containers to see which is newer.

To implement CompareTo the Chutzpah test container includes a timestamp field. When the container gets created the timestamp is set to the last modified time of the file (whose path is the source property). The CompareTo method checks if the sources are the same and then compares their timestamps:

public int CompareTo(ITestContainer other)
{
    var testContainer = other as JsTestContainer;
    if (testContainer == null)
    {
        return -1;
    }

    var result = String.Compare(this.Source, testContainer.Source, StringComparison.OrdinalIgnoreCase);
    if (result != 0)
    {
        return result;
    }

    return this.timeStamp.CompareTo(testContainer.timeStamp);
}

You can view Chutzpah’s implementation of ITestContainer in JsTestContainer.cs.

ITestContainerDiscoverer

A container discoverer is responsible for finding test containers and returning them to the UTE. It has a simple interface:

public interface ITestContainerDiscoverer
{
	Uri ExecutorUri { get; }
	IEnumerable<ITestContainer> TestContainers { get; }
	event EventHandler TestContainersUpdated;
}

• ExecuteUri – A string which uniquely identifies a test adapter. This string is used to tie a container discoverer with a test discoverer and executor.
• TestContainersUpdated – An event to invoke when test containers are found or are changed.
• TestContainers – A property which returns the discovered test containers. This is called when the UTE when a solution is first loaded, before unit tests are executed and after you fire the TestContainersUpdated event.

Since the TestContainers property is called often it is crucial that it returns quickly. In Chutzpah’s initial implementation the whole solution was scanned each time looking for test files and returning containers for them. This was far too slow. Thus, the current implementation it keeps a cached list of test containers which are updated incrementally by monitoring solution and file events. When the TestContainers property is called the cached list is returned.

To manage the cached list of test containers the container discoverer subscribes to IVsSolutionEvents for solution events, IVsTrackProjectDocumentsEvents2 for project events and use a FileSystemWacther for file events.

IVsSolutionEvents fires events when projects and solutions are loaded and unloaded. When a project is loaded the discoverer scans for JavaScript files, checks if they contain tests and adds them to the containers list. On project unload its test containers are removed from the list. IVsTrackProjectDocumentsEvents2 fires events when a file is added, removed or renamed in a project. When these events occur test containers are added or removed. FileSystemWacther fires events when the content of the file has changed. File watchers are added to monitor each JS file in the solution to detect when they change. Whenever a change happens the test container list is updated with a new instance of a test container and the old instance is removed.

To help keep the list of test containers small the container discoverer doesn’t create test containers for all JS files. When an event occurs on a file it is opened and checked to see if it contains tests. If it does then a test container for it is added to the list. This saves the ITestDiscoverer from needed to do extra work and results in a quicker testing experience.

You can see the implementation of these interfaces in JsTestContainerDiscoverer.cs, SolutionEventsListener.cs, TestFileAddRemoveListener.cs and TestFilesUpdateWatcher.cs.

ITestDiscoverer

Now that the UTE has the test containers the next step is discovering what tests are within them. The UTE looks for an implementation of ITestDiscoverer that has an DefaultExecutorUri attribute set to the same value as the ExecutorUri property in ITestContainerDiscoverer.

This interface contains one method.

public interface ITestDiscoverer
{
  void DiscoverTests(
          IEnumerable<string> sources,
          IDiscoveryContext discoveryContext,
          IMessageLogger logger,
          ITestCaseDiscoverySink discoverySink);
}

The key arguments are sources and discoverySink. Each string in the sources corresponds to the Source property on a test container. The discoverySink argument is an instance of ITestCaseDiscoverySink which also contains one method:

public interface ITestCaseDiscoverySink
{
  void SendTestCase(TestCase discoveredTest);
}

For each source in the sources list the test discoverer will open that file and scan it for tests. For each test found a test case object is created and sent to the discovery sink.

In addition, the test discovery implementation needs the FileExtension attribute set to the file extension the discoverer is interested, for Chutzpah this is .js. Here is Chutzpah’s test discovery class:

[FileExtension(".js")]
[DefaultExecutorUri(Constants.ExecutorUriString)]
public class JsTestDiscoverer :ITestDiscoverer
{
    public void DiscoverTests(IEnumerable<string> sources,
                              IDiscoveryContext discoveryContext,
                              IMessageLogger logger,
                              ITestCaseDiscoverySink discoverySink)
    {
        var chutzpahRunner = TestRunner.Create();
        foreach (var testCase in chutzpahRunner.DiscoverTests(sources))
        {
            var vsTestCase = testCase.ToVsTestCase();
            discoverySink.SendTestCase(vsTestCase);
        }
    }
}

You can also view this on CodePlex in JsTestDiscoverer.cs.

ITestExecutor

And finally we arrive at the last step in the process which is test execution. A test executor implements the ITestExecutor interface and has an ExtensionUri attribute on it that defines the executor uri we saw earlier. The ITestExecutor interface contains three members:

public interface ITestExecutor
{
  void RunTests(IEnumerable<string> sources, IRunContext runContext, IFrameworkHandle frameworkHandle);
  void RunTests(IEnumerable<TestCase> tests, IRunContext runContext, IFrameworkHandle frameworkHandle);
  void Cancel();
}

• RunTests(string) – Called when running all tests. It receives a collection of strings which correspond to the sources in the test containers.
• RunTests(TestCase) – Called when running selected tests. Chutzpah doesn’t yet support running individual tests (it runs the whole js file). It will grab the test container source from the TestCase object and call the other RunTests method that takes a list of test container sources.
• Cancel -  Called when the user tries to cancel the test. Chutzpah doesn’t implement this yet.

Here is Chutzpah’s test execution class:

[ExtensionUri(Constants.ExecutorUriString)]
public class JsTestExecutor : ITestExecutor
{
  public void Cancel()
  {
          // Will add code here when streaming tests is implemented
  }

  public void RunTests(IEnumerable<string> sources, IRunContext runContext, IFrameworkHandle frameworkHandle)
  {
          if (runContext.IsDataCollectionEnabled)
          {
              // DataCollectors like Code Coverage are currently unavailable for JavaScript
              frameworkHandle.SendMessage(TestMessageLevel.Warning, "DataCollectors like Code Coverage are unavailable for JavaScript");
          }

    var chutzpahRunner = TestRunner.Create();
    var callback = new ExecutionCallback(frameworkHandle);
    chutzpahRunner.RunTests(sources, callback);
  }

  public void RunTests(IEnumerable<TestCase> tests, IRunContext runContext, IFrameworkHandle frameworkHandle)
  {
    // We'll just punt and run everything in each file that contains the selected tests
    var sources = tests.Select(test => test.Source).Distinct();
    RunTests(sources, runContext, frameworkHandle);
  }
}

In the above code the IFrameworkHandle argument on the RunTests is wrapped in an ExecutionCallback class. This class implements the TestFinished callback that Chutzpah calls when running tests. The results of the test are converted into TestCase and TestResult objects and are passed to methods on the IFrameworkHandle object. The IFrameworkHandle interface inherits from ITestExecutionRecorder which provides methods for recording the beginning, end and results of a test case.

  public interface ITestExecutionRecorder : IMessageLogger
  {
    void RecordResult(TestResult testResult);

    void RecordStart(TestCase testCase);

    void RecordEnd(TestCase testCase, TestOutcome outcome);

    void RecordAttachments(IList<AttachmentSet> attachmentSets);
  }

Inside of TestFinished, the methods RecordStart, RecordResult and RecordEnd are called:

public void TestFinished(Chutzpah.Models.TestResult result)
{
  var testCase = result.ToVsTestCase();
  var vsresult = result.ToVsTestResult();
  var outcome = result.ToVsTestOutcome();

  // The test case is starting
  frameworkHandle.RecordStart(testCase);

  // Record a result (there can be many)
  frameworkHandle.RecordResult(vsresult);

  // The test case is done
  frameworkHandle.RecordEnd(testCase, outcome);
}

It may seem odd that Chutzpah is invoking both RecordStart and RecordEnd from its TestFinished method but this is a result of Chutzpah’s execution of test files. Chutzpah executes the whole  JS  test file and collects the results. This means that it can’t notify when an individual test has started until the test is already completed. There are plans to change this in the future by adding the ability to stream test results while a test file is running.

You can view Chutzpah’s implementation of ITestExecutor in JsTestExecutor.cs.

Debugging Test Adapters

The UTE will call into the interfaces listed above from three different processes. In order to debug, you must be attached to the correct ones.

• ITestContainerDiscoverer is called from the main Visual Studio process named devenv.exe. This is the default process you attach to when debugging.
• ITestDiscoverer is called from a process named vstest.discoveryengine.x86.exe. This process starts when the UTE is first opened.
• ITestExecutor is called from a process named vstest.executionengine.x86.exe. This process starts during first discovery pass.

If you are attached to all three then you can be sure that your breakpoints will be hit.

That was a quick tour of Chutzpah’s test adapter implementation. When the final version of Visual Studio 2012 is released I will update this post to reflect any changes.

Happy Snippeting!