Partilhar via

Microsoft Protocol Test Suites Available

  • Artigo

We recently released a set of Microsoft Protocol Test Suites. OK it was a month ago, but we’ve been really busy…really! To access them you must have a Live ID and sign up. These Test Suites allow you to evaluate whether a protocol implementation meets certain interoperability requirements. They don’t cover every protocol requirement but can be a useful indication of interoperability. Plus all the source code is included so that you can extend them.

If you are involved in interoperating with Microsoft products, these Test Suites can provide some valuable information. Also be sure to check out all of our Interoperability Testing Links.

Comments

  • Anonymous
    January 01, 2003
    thanks
  • Anonymous
    January 01, 2003
    Hi, I am Glad to hear about this initiative and your article. I guess it would be right to ask you some suggetion regarding a problem I got struck in the proess of developing a TestSuites-Automation-Framework. Automation-Framework is to verify BROWSER conformance to W3C Standards. A set of testcases, are authored upon understanding the STANDARD, and its IMPLEMENTATION. Framework testcases inside an "iFrame" of browser-under-test, and evaluates its result. Such results should be logged onto persistent storage, for which a PHP application is written for appending/creating files and data. But, this LOGGING is not possible when I run the testsuite from a mobile-phone that has a browser altering websites to display optimally on phones. In such a case, this LOGGING is not working in expected manner. I am referring to that content-altering-process-on-mobile as a PROXY-MODE. I pasted code-snippets for your reference.
  1. All the test-cases that are to be evaluated are specified in an Array named tests. Example, var tests = new Array("TestCase001.html", "TestCase002.html","TestCase003.html”, ---so on till--- ,"TestCase00n.html");
  2. test-cases are loaded one after another in an iFrame (1st feature, described in previous mail).   2.1 As loading a test-caseevery time in the same iFrame did not fire the load event (in proxy-mode); we are removing and re-creating the iFrame every time when it need to load a new test-case. This also ensures that un-necessary garbage is cleared and keeps memory afresh. /** Code to remove iframe from DOM and re-create to load next test **/   try   {       var fRef = document.getElementById(destFrame);       document.body.removeChild(fRef);   }   catch(exception)   {       console.log("unable to remove child");   }   try   {       var tFrame = document.createElement('iframe');       tFrame.setAttribute("id", destFrame);       document.body.appendChild(tFrame);   }   catch(exception)   {       console.log("unable to add child");   }   2.2 Get the reference for next test-case and load it into iFrame.   document.getElementById(destFrame).setAttribute(“src”, <<next test case reference in ‘tests’ array>>);
  3. Once a test-case loads, test-case evaluation logic runs (in iFrame’s context) and notifies result of that test-case to its parent window (we used “window.top” property). Now, we cache the result in a Javascript variable (2nd feature) and log the results on to a persistent storage for every ‘N’ number of cases using php (3rd feature, we are referring this as ‘chunk-logging’). Javascript AJAX API is used to POST the request to php file. As we found some problem in logging the results in “proxy-mode”, for testing purpose we tried parameterizing test-result as a GET parameter and setting “src” attribute of an iFrame to that php file without using AJAX (Kindly note that this modification is made only for testing purpose to identify the issue in proxy-mode and shall be reverted to its original form – ‘chunk logging’).   var fRef = document.getElementById("firstFrame");   fRef.setAttribute("src",<<location of php file>>+"?fileName=<<log file name>>&_POST_TEST_RESULTS="+<<result to log>>);