Passing tests are now at 672 of 899 668bac0551. I have added a few ignored tests for the mysql db tests bringing the ignored tests total to 162.

Top failure causes:

• Issues relating to dropping of foreign constraints at umbracodomains
• issues relating to test initialisation
• Errors due to mono implementation differences.

To get the tests to work at this stage, I added a Configuration settings injector – this is because NUnit is not able to find and load the appropriate configuration settings. This is a bigger topic than I can give it justice here.

Overall the test area will need quite a bit of work, if we want to achieve out-of-the-box native testing capability.

I have started working on the 6.0.3 tests: commit hash 648b701599. Out of the box 324 / 1061 tests were passing. All of the database tests are (of course being written with SQLCE) failing. The test code itself looks to be in a transitional stage from the sqlHelper based set-up towards using petaPoco.

With a bit of coaxing, I have increased passing tests to 390. The increase comes mainly from non-database based tests. Some of the database based tests are passing in the ‘legacy’ setting – using the MySqlTestHelper.

I have been going through these tests very quickly as there are quite a lot of them… The testing strategy I am using has required big changes to the underlying source code – i.e. the replacement of all calls to configuration manager – of which there are quite a lot now. I would recommend having a mockable wrapper class for these calls – at some point.

I ll be continuing and looking at the database based tests next.

Ok the 6.0.3 version is working now (git hash 17411e5c8a), and I have tested it for the most basic things. In general, so far so good.

I also started separating all of the ‘Multiplatform’ code into its own namespace (in Umbraco.Core.MultiPlatform). As a first step everything is in static functions.

However, I have also observed three behaviours, the cause of which I do not know at the moment, and which are problematic. Here’s the list:

• EditMemberTypes – renders ‘Allow Only at root’ in Firefox
• The first hit on the root page after ‘Publish’ gives a 404. Second hit produces the page
• Firefox: sometimes hangs and the javascript debugger kicks in

I will have a look at these in due course. The next step is to get the tests passing and to run through setting up a sample site. While the UI loads fine and we got basic functionality, there are parts that i have not yet ported; and sorting those out is next. I am hoping that when that is all done, I can have a look at the above snagging list.

Yay! As of 80c6589fec, the 6.0.3 UI is now loading. Let’s hit the highlights:

• Application Initialization: CacheHelperApplicationEventListener and HttpContext.Current are initialised twice during start up and this breaks initialisation. I wrote some workaround code for now. I think there may be some mono differences during application start up or some threading issues. This will need a closer look. However, at first look the app startup code does look possibly too heavy.
• This setting breaks mysql server initialisation in Linux:

  lower_case_file_system=1
  

  The setting does not work in linux / unix as it is ‘read only’ (here). So I have also disabled this check if we hit a linux / unix platform set-up. We could have kept the check, but this would automatically disable Umbraco mysql install on the majority of Linux systems, which by default have a case sensitive file system set-up. Oh, and adding the setting to the my.cnf file in arch linux causes the mysql daemon start up to fail. So, adding it to the mysql config file may break your server.

That’s it for now.

Finally time for a progress report on 6.0.3 – I have finally started on this and there is now a git branch called ‘u6.0.3′. With this change set (1cd0904b19), version 6.0.3 compiles in Monodevelop 4. The overall changes were minimal. However, some preliminaries are required.

Here are the preliminaries:

• Monodevelop: As of today, you will need git rev cfb8e3bc5d or c1cecf5931. Avoid rev b916eecb8c, as this rev does not compile cleanly. We need these changes so that references are updated correctly in the .csproj files.
• Nuget package restore. There is a tool available for this in:

  $ tools/mono/RestoreNugetPackages.sh

  This is a blunt tool and restores all packages, including Microsoft.Web.Infrastructure, which we actually do not want, as we will be using Mono’s corresponding dll. So project references need to re-adjusted afterwords.

• The shell script above uses a small custom build task. I was only able to write this as a C# assembly. I could not write it as an inline build task, as xbuild was throwing errors. The build task itself fixes another xbuild bug, namely incorrect handling of the ‘;’ and ‘\’ character. The former is always interpreted in the unix context, and the latter is always converted to ‘/’. Related info here.
• Finally, as Mono does not yet fully support native MVC 4, I have switched to using the stock ASP.NET stack that we get from NuGet. We will see what kind of mileage we will get from these.

478 / 499 (the 500th test does not contain any active tests) tests are passing. Of the remaining 21 tests, cause of failures are:

• Partial Trust: …(ReportsFailure) – I have not been able to get these to work. Apparently in mono CAS (Code Access Security) is experimental and unsupported. I have not been able to enforce Reflection Access restrictions in test code, nor have I been able to debug it in an NUnit test instance. Please see here for details.

  In mono it appears that,

  SecurityManager.SecurityEnable returns false unless
  mono is run with the --security option.
  

• Published Content: DynamicNode, DynamicPublishedContent, DynamiXml, StronglyTypedQuery tests – Not sure yet if failure is because of test set-up differences or a genuine implementation difference in the .NET mono implementation.
• Published Content: DynamicNode Get_Member_Property fails because it needs some additional test database initialisation, namely the alias of the parent document type. (TO DO)

Summary: All is looking good but both the Partial trust and DynamicNode / PublishedContent / Xml tests indicate that there may be some issues due to implementation differences. This will need further clarification and testing.

Git commit hash a1f5565762

The Umbraco HQ team has done a great job with the tests, and the testing architecture. I have done a few small changes, e.g. moving the test database over to MySql by way of an MySqlTestHelper.

At present about 269 /500 tests are passing. Some of the failing tests pass when run individually. This has been a slow laborious process, and Monodevelop has been frequently freezing after failing tests.

I will need to update my own test (4.7.2) code at some point. I am using it here but it is not a good architectural match, and will need to be refactored.

For compatibility it might be good in the future to move the test database to SqlLite – or another db that can be used in Windows and non-Windows environments.

I have started testing Razor and Mvc features. Here are the important bits:

• XPathNodeIterator MoveNext issues revisited:

  Example:
  if (media != null && media.Current != null)
  {
      media.MoveNext();
      ...
  }
  

  Does not work in mono, as until MoveNext() is called Current is always null.

• ‘Could not locate Razor Host Factory type: umbraco.MacroEngines.RazorUmbracoFactory, umbraco.MacroEngines’ error message – this stems from a bug in mono. The quick resolution is to use either one of the two below:

  In web.config use:
    <system.web.webPages.razor>
      <host factoryType="umbraco.MacroEngines.RazorUmbracoFactory" />
  
  or use
    <system.web.webPages.razor>
      <host factoryType="umbraco.MacroEngines.RazorUmbracoFactory, umbraco.MacroEngines, Version=1.0.4832.22841, Culture=neutral, PublicKeyToken=null" />
  

  The ‘bug’ is in the mono type enumerator:

  In mono System.Web.Compilation > BuildManager > public static Type GetType (string typeName, bool throwOnError, bool ignoreCase)
  
  ...
  	var aname = new AssemblyName (typeName.Substring (comma + 1));
  	wantedAsmName = aname.ToString ();
  ...
  	if (String.Compare (wantedAsmName, asm.GetName ().ToString (), StringComparison.Ordinal) == 0) {
  ...
  

  Looks for an exact match in assembly name if one is supplied

• Some razor logic seems to produce a compiler error:

  @inherits umbraco.MacroEngines.DynamicNodeContext
  @{
  	var level = String.IsNullOrEmpty(Parameter.Level) ? 1 : int.Parse(Parameter.Level);
  	var ulClass = String.IsNullOrEmpty(Parameter.UlClass) ? "" : String.Format(" class=\"{0}\"", Parameter.UlClass);
  	var parent = @Model.AncestorOrSelf(level);
  	if (parent != null) { ** fails here **
           ....
  	}
  }
  

  Produces ‘single file build failed,’ and this can be traced back to a lock in the mono System.Web.Compilation > BuildManager.cs > static void Build (VirtualPath vp) > line 404.

  ...
          static readonly object bigCompilationLock = new object ();
  ...
  	CompilationSection cs = CompilationConfig;
  	lock (bigCompilationLock) {
  

  This is the most serious error so far, and needs some investigation. However, in this case, removing the null check is sufficient to make the compilation succeed, and workarounds therefore, may exist.

• Summary 1: in addition to casing issues, the XPathNodeIterator MoveNext issue is emerging as a key issue.
• Summary 2: Razor and MVC functionality will need further testing.

OK, the Content area is now finished as well. All superficial UI functions have now been fixed. The latest round of fixes address some important mono differences:

• 1f54a0c35f – Our good friend: To initialise an XPathNode Iterator, call MoveNext() first. Content > Public Access was throwing errors, which were fixed with MoveNext calls (via the introduction of an XmlHelper method).
• 7ee981a56b – The mono multiline text box control tab injection bug was fixed by some jQuery
• 3b7f42c97b – The false positive in the xss check when first logging in was fixed as well. This error originated because mono treats absolute paths starting with ‘/’ as a file system path (in the Uri class), and sets the Host name to an empty string.

The users area is now completed as well. Again, this was pretty much smooth sailing, except that in the edit user type section, the dynamic checkbox list was losing its state. Again, I applied a local fix. So the dynamic checkbox state issue is revealing itself to be quite significant.

I have also started on the Content area. More on that in the next post.