En terme de rédaction du test, cela donne ça:

Feature: Test with ASP.net
	In order to get test coverage of my ASP.Net Application
	As a developper
	I want to run an embeded ASP.Net server in my NUnit test

@selenium
Scenario: Say Hello to Michel
	Given I'm on the default page
	When I enter the name "Michel"
	And I click the "SayHello" button
	Then the message is "Hello Michel"

Grâce à Specflow, je peux donc rédiger mon scénario en anglais, très lisible par l’utilisateur qui va pouvoir ainsi exprimer son besoin.
Ces phrases sont ensuite couplées à des méthodes C# qui effectuent une partie du test. Exemple:

[When("I click the \"SayHello\" button")]
public void IClickTheSayHelloButton()
{
    selenium.Click("SayHelloButton");
    selenium.WaitForPageToLoad((1 * 60 * 1000).ToString());
}

On remarque ici que j’utilise Selenium pour simuler le scénario et effectuer un click sur un bouton de la page.

Petite astuce: le scénario est “tagué” @selenium. Grâce à ce tag, je peux indiquer qu’il faut initialiser Selenium à chaque début de scénario tagué ainsi.

[BeforeScenario("selenium")]
public void BeforeScenario()
{
    var firefoxPath = Path.GetFullPath(
        Path.Combine(AppDomain.CurrentDomain.BaseDirectory, @"..\..\..\Libs\Firefox\firefox.exe"));
    var selenium = new DefaultSelenium("localhost",
                                       4444,
                                       @"*firefox " + firefoxPath,
                                       "http://localhost:8123");
    ScenarioContext.Current["selenium"] = selenium;
    selenium.Start();
}

OK, je suis content avec ça, je peux maintenant rédiger des tests fonctionnels lisibles et les automatiser à l’aide de Selenium.
Mais cela ne me donne pas la couverture du code de mon application .Net qui se trouve hébergée sur un serveur IIS

Afin d’avoir la couverture du code de toute l’application, j’ai alors décider d’exécuter l’application ASP.Net à l’intérieur du processus du test unitaire!
Afin d’héberger l’application ASP.net, j’utilise pour cela la librairie de Mono: XSP.
Pour cela, quelques lignes de codes suffisent:

[BeforeTestRun]
public static void BeforeTestRun()
{
    const int port = 8123;
    string path = Path.GetFullPath(@"..\..\..\MyApp.Web");
    const string webServerFileName = "Mono.WebServer2.dll";

    string sourcePath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, webServerFileName);
    string destinationPath = Path.Combine(Path.Combine(path, "bin"), webServerFileName);

    File.Copy(sourcePath, destinationPath, true);

    var websource = new XSPWebSource(IPAddress.Any, port);
    webAppServer = new ApplicationServer(websource);
    webAppServer.AddApplication("localhost", port, "/", path);
    webAppServer.Start(true);
}

[AfterTestRun]
public static void AfterTestRun()
{
    webAppServer.Stop();
}

Simple non?

Voila alors le résultat:

Afin de pouvoir tester par vous même, vous pouvez télécharger les sources depuis http://bitbucket.org/grozeille/testwithaspdotnet/src/, lancer le serveur Selenium à l’aide de “SeleniumServer.bat“, lancer les tests avec “Test.bat“, et voir le rapport de couverture de code avec Libs\PartCover .NET 2\PartCover.Browser.exe en ouvrant le fichier Coverage.Xml.
Ça, ça rox du poney!

• Comment fonctionne un HttpHandler?
• Pourquoi ne pas utiliser les UpdatePanels?
• A quoi sert un MembershipProvider et comment s’en servir?

Si ces questions vous paressent obscures et que vous êtes plutôt un développeur “glisser-déposer”, alors je vous propose de vous “glisser-déposer” sur un autre blog

Pour les autres, j’ai un aveu à vous faire: je viens de découvrir qu’il n’est pas possible d’afficher 2 pages ASP.Net en simultané si elles accèdent à la Session.

J’ai cru que j’étais sous l’effet d’une drogue… mais non, c’était bien vrai.
J’ai alors voulu en avoir le cœur net, et j’ai fouillé de nombreux forums… c’est la que j’ai découvert que d’autres l’on découvert après 5 ans d’expériences en ASP.Net!!!

Certes, on ouvre rarement 2 pages Web d’un même site, mais il est plus fréquent d’avoir 2 appelles Ajax en simultané.
C’est mon cas, car j’aime Ajax, j’aime le Web, et j’utilise une technique “Comet” appelé “Long Pooling”. Cela consiste à faire un appelle Ajax potentiellement infinie, qui va se terminé seulement si le serveur à quelque chose à nous dire. Cela permet d’avoir un système de notification très simple à implémenter.

Pour vulgariser, au lieu d’avoir ça:

Client: “Tu veux me dire quelque chose?”
Server: “Non”
Client: “Tu veux me dire quelque chose?”
Server: “Non”
Client: “Tu veux me dire quelque chose?”
Server: “Mais lâche moi sale client!!!”

En long polling ça donne ça:

Client: “Bon, tu me préviens si t’as un truc à me dire…”
Server: “…”
Server: “…”
Server: “…”
Server: “…”
Server: “… ouai, j’ai un truc pour toi, un nouveau message”
Client: “OK, je le traite, bon, tu me préviens si t’as un autre truc à me dire…”

Et sinon, en C# ça donne ça:

public string LongAjaxCall()
{
    string result = null

    while(result == null)
    {
        lock(this.notificationList)
        {
            if(notificationList.Count > 0)
            {
                result = new JavaScriptSerializer().Serialize(this.notificationList.ToArray());
                this.notificationList.Clear();
            }
        }
        if(result == null)
            Thread.Sleep(500);
    }
}

En général, le serveur n’a pas les mêmes choses à dire aux différents clients, c’est pourquoi on utilise la Session. Mais cette dernière est verrouillée par le long pooling, l’utilisateur ne sera alors pas en mesure d’ouvrir une nouvelle page si l’appelle Ajax ne se termine pas, ce qui est plutôt fâcheux.

Et Spring.Net dans tout ça?

J’utilise massivement Spring.net, pas seulement pour l’IOC, mais pour bien d’autres choses que ce merveilleux framework offre.
Dans le cadre d’une application Web, il est possible d’avoir un “scope” pour les instances des objets:

• application: un singleton pour toute l’application Web
• session: l’instance n’existe que dans le cadre d’une session ASP.Net
• request: l’instance n’existe pour pour la duré de la requête HTTP

J’utilise pas mal le scope “Session”, afin d’instancier des “contrôleurs” différents pour chaque utilisateurs. Je peux ainsi conserver un état à l’aide des membres de mes contrôleurs (ou conserver une connexion SQL, etc.).

Je vous propose alors de jeter un œil à mon exemple afin de comprendre mon problème: http://bitbucket.org/grozeille/testaspsessionmultithread/src
Cette solution contient un premier exemple “TestASPSessionMultithread.Bad” qui illustre mon problème.

L’exemple est simple:
Vous avez une première page “Default.aspx” qui permet d’ajouter une “string” à une liste à l’aide du button “add” qui effectuera un appelle Ajax.
Vous pouvez alors ensuite déclencher un “long pooling” à partir du boutton “long polling” qui va demander au serveur de renvoyer les nouveaux items.

Dans cet ordre, tout va bien. Par contre, si vous faite un “long pooling” en premier, le boutton “add” restera bloqué et il sera donc impossible d’ajouter un nouvel item.

De même, vous pouvez tester aussi la page “Other.aspx” qui simule un lourd traitement qui prend 5 secondes. Quand vous essayer d’ouvrir la page “Other” et que vous tentez de recharger la page “Default” en parallèle, cette dernière va attendre la fin du chargement de la page “Other”.

A noter aussi que j’affiche le “creation time” des différents contrôleurs. Puisque Spring.Net permet d’avoir du LazyLoad, on voit que le OtherController est créé après le DefaultController.

Si vous regardez le code en détail, vous pouvez voir que je gère les appelles Ajax à l’aide d’un HttpHandler custom.
Je pense que le code est suffisamment bien commenté pour le comprendre, et pour ceux qui ont la flemme de récupérer le source depuis BitBucket, voici l’extrait:

public class BadAjaxHttpHandler : IHttpHandler, IRequiresSessionState
{
    public void ProcessRequest(HttpContext context)
    {
        // get the name of the controller and the action from the URL
        var action = context.Request.Url.Segments[context.Request.Url.Segments.Length - 1];
        var controller = context.Request.Url.Segments[context.Request.Url.Segments.Length - 2]
            .Replace(".ajax", string.Empty)
            .Replace("/", string.Empty);

        // get the instance of the controller thanks to its name
        var instance = ContextRegistry.GetContext().GetObject(controller);

        // get the method of the controller thanks to reflection
        var method = instance.GetType().GetMethod(action, BindingFlags.Instance | BindingFlags.Public);
        var args = new List();
        foreach (var item in method.GetParameters())
        {
            args.Add(TypeDescriptor.GetConverter(item.ParameterType).ConvertFromString(context.Request.Params[item.Name]));
        }

        // invoke the method of the controller
        var result = method.Invoke(instance, args.ToArray());

        // return the JSON value of the method result
        context.Response.Write(new JavaScriptSerializer().Serialize(result));
        context.Response.StatusCode = 200;
        context.Response.End();

On remarque que pour accéder à la session nous avons ici besoin d’implémenter l’interface “IRequiresSessionState”, mais la aussi, comme c’est en lecture/écriture, cela verrouille la session le temps de la requête HTTP.

Comment résoudre le problème?

La solution est dans le projet “02-TestASPSessionMultithread.Good.Unsecured”.

Pourquoi “Unsecured” ? On verra ça plus tard.

La solution est simple, il suffit d’accéder à la Session en “lecture seule”.
En effet, il peut être problématique d’ajouter une même clé depuis 2 thread concurrents, mais une fois que la clé est créée, c’est à vous de gérer la concurrence de la valeur.

Exemple:

Session[“list”] = new List(); // problème de concurrence, donc session verrouillée

((List)Session[“list”]).Add(“toto”); // ce cas est une lecture seule de la session, mais à vous de gérer la concurrence pour la collection

Comme Spring.Net est en quelque sorte une “grosse collection d’instance”, et que Sprint.net utilise une seule clé “spring.object”, cela s’applique aussi

Par défaut, les pages sont en accès Write à la session. Pour changer cela, il faut ajouter une option dans l’ASPX:

<%@ Page EnableSessionState="ReadOnly"  %>

Il a fallut un petit changement dans le HttpHandler Ajax aussi:

public class AjaxHttpHandler : IHttpHandler, IReadOnlySessionState

Cette nouvelle interface “IReadOnlySessionState” parle d’elle même

Et voila! C’est tout! Ca marche, plus de problème de concurrence!
Enfin… non ce n’est pas tout, on a un petit problème, c’est que Sprint.net ne pourra plus jamais initialiser la session sans accès en écriture
Il faut donc trouver un “bootstrap” qui accède à la session en écriture juste le temps de créer le contexte Spring.Net.

L’astuce est donc de faire une redirection vers un HttpHandler particulier “SpringSessionHttpHandler” si la session est nouvelle. Il peut alors accèder à la session en écriture grâce à l’interface “IRequiresSessionState” pour initialiser le contexte et rediriger vers la page d’origine.

Ceci est fait lors du “OnLoad” car nos pages héritent de “SessionPage”.

public class SessionPage : Page
{
    protected override void OnLoad(EventArgs e)
    {
        // build the spring.net session
        if (Session.IsNewSession)
        Response.Redirect("SpringSessionHttpHandler?ReturnUrl=" + Server.UrlEncode(Request.Url.ToString()), true);

        base.OnLoad(e);
    }
}

Le code du HttpHandler est très simple: il force la création du contexte Spring dans la session, puis redirige sur la page d’origine qui elle a un accès en lecture seule sur la session.

public class BadAjaxHttpHandler : IHttpHandler, IRequiresSessionState
    {
        public void ProcessRequest(HttpContext context)
        {
            // get the name of the controller and the action from the URL
            var action = context.Request.Url.Segments[context.Request.Url.Segments.Length - 1];
            var controller = context.Request.Url.Segments[context.Request.Url.Segments.Length - 2]
                .Replace(".ajax", string.Empty)
                .Replace("/", string.Empty);

            // get the instance of the controller thanks to its name
            var instance = ContextRegistry.GetContext().GetObject(controller);

            // get the method of the controller thanks to reflection
            var method = instance.GetType().GetMethod(action, BindingFlags.Instance | BindingFlags.Public);
            var args = new List<object>();
            foreach (var item in method.GetParameters())
            {
                args.Add(TypeDescriptor.GetConverter(item.ParameterType).ConvertFromString(context.Request.Params[item.Name]));
            }

            // invoke the method of the controller
            var result = method.Invoke(instance, args.ToArray());

            // return the JSON value of the method result
            context.Response.Write(new JavaScriptSerializer().Serialize(result));
            context.Response.StatusCode = 200;
            context.Response.End();
        }

Mais quel astuce géniale! …mais pourquoi “Unsecured” ?

Vous pouvez remarquer que j’affiche l’ID de la session dans la page.
L’identifiant de session est stocké par défaut dans un cookie. J’ai tout de même changé le nom de ce dernier, car si je laisse la valeur par défaut, je risque d’avoir un conflit avec une autre application (erreur de débutant)

<sessionState cookieName="TestSession"/>

Normalement, le cookie est “sécurisé”, cad qu’il n’est pas accessible depuis du Javascript malicieux.
Mais bon, un cookie ça reste quand même pas super sécurisé.

Si vous voulez tester un vol de session, il vous suffit de copier/coller l’ID de la session dans un cookie d’un autre navigateur.

Comment faire alors pour sécuriser le tout? Vous avez pour cela différentes solutions:

• implémenter votre propre gestion d’ID de session avec <sessionState customProvider=”MonType”>, et vérifier l’identité à l’aide de critère comme l’IP du client
• coupler la session avec l’authentification

C’est cette dernière solution que je vais vous présenter, car c’est la plus simple.
L’authentification en ASP.Net se fait à l’aide du MembershipProvider, que vous pouvez implémenter vous même. Le framework .Net va alors gérer l’identité à l’aide d’un cookie aussi, mais ce dernier est beaucoup plus sécurisé et vous pouvez y faire confiance.
Je vais alors stocker dans la session la valeur du cookie d’authentification, et vérifier donc l’identité avant d’accéder à la session.

Vous pouvez vérifiez cela par vous même à l’aide du projet 03-TestASPSessionMultithread.Good.Secured
Si vous tentez de voler le cookie d’authentification pour l’utiliser sur un autre navigateur, vous serez alors déconnecté. Si vous tentez de voler le cookie de session, vous serez alors aussi déconnecté.

Les pages hérites alors de “SecuredSessionPage”, et vont alors vérifier le cookie de session dans le “OnLoad“:

// if the user tried to steal the session of another user
if (Page.Request.Cookies[FormsAuthentication.FormsCookieName] == null ||
    !Equals(Page.Request.Cookies[FormsAuthentication.FormsCookieName].Value, Session[FormsAuthentication.FormsCookieName]))
{
    this.Logout();
}

Je vous laisse ensuite découvrir l’implémentation de l’authentification, mais ce n’est pas le sujet de ce billet et il n’y a rien de plus classique.

Conclusion

Si comme moi vous utiliser Spring.net avec ASP.net et que vous avez des problèmes de lenteur, essayer cette astuce

J’avais dit qu’il manquait un équivalent à EasyPhp pour .Net, et on m’a fait remarqué d’un “IIS Express” pointait le bout de son nez…
WebMatrix est donc un gros Setup qui t’installe sur ta machine un IIS Express, un base de donnée Express, et un IDE Express (et d’autres trucs Express).

Je n’ai pas encore eu le temps de tester tout ça, mais on voit déjà la grosse machine commerciale!
Le site Web est très bien fait, avec plein de mots à la mode: D.R.Y, MVC, TDD, une petite screenshot de NerdDinner, tout pour plaire

Il y a un gros effort sur l’aspect “Communauté”, on peut facilement installer une application Web, .Net/PHP/autres, en quelques clicks.
A noter aussi le gros effort sur la documentation, tutoriel et compagnie,  pour que tout le monde puisse “faire du Microsoft rapidement”.

J’ai l’air de ne pas aimé? Ça se voit?

Bon, premièrement, je suis sous Ubuntu à cet instant précis ou je vous écris.
Ensuite, les vidéos Silverlight ne fonctionnent pas: Moonlight crash sous Google Chrome, et sous Firefox la vidéo ne se lance pas.
Enfin, si vous faite joue joue avec WebMatrix, vous allez vouloir déployer ça quelque part…
Ça tombe bien, Microsoft recommande pleins de “Hosting partner” avec du Windows Server 2008 R2… et du SQLServer bien sûr.

Revenons à EasyPHP.
Avec EasyPHP, vous avez un vrai Apache (pas une version Express) avec un vrai MySQL (pas une version Express).
Il existe aussi bien sûr des “EasyPHP like” avec du PostgreSQL, tout est possible.
Vous pouvez ensuite héberger cela sur du Windows si vous voulez… ou du Linux.

Bon, c’est vrai, EasyPHP n’installe pas un IDE, il va falloir en trouver un gratuit.
Ca doit être plutôt rareun IDE gratuit, d’après ce que l’on voit sur le site de WebMatrix:
Je cite: “Cerise sur le gâteau, c’est entièrement gratuit.”

Allez, parce-que je suis gentil, voici 3 IDE PHP gratuit:

• http://www.phpide.de/
• http://www.php-editors.com/
• http://www.phpide.de/

Le gros + de WebMatrix, c’est quand même de pouvoir télécharger n’importe quel application Web (ASP.Net et PHP) en quelques clicks. La, j’avoue, rien à dire.

Je vous laisse maintenant apprécier  la grandeur commerciale de Microsoft, je pense qu’ils vont réussir leur coup avec WebMatrix.

Pour conserver une trace de mon incompétence, voici donc la solution:
Pour qu’on puisse dialoguer avec un service WCF dans une page Asp.net, je leur injecte un proxy à l’aide de Spring (voir Spring.net pour le web). Pour cela, j’utilise une “factory de proxy” à l’aide de l’interface IFactoryObject.
Crédule que j’étais, j’imaginais que le fait de retourner true pour la propriété IsSingleton allait faire en sorte que Spring.net ne fasse appel qu’une seule fois à la méthode GetObject().
Et bien non ! C’est à vous d’être cohérent: même si IsSingleton retourne true, rien ne vous empêche de toujours retourner une instance différente dans la méthode GetObject().

Pour en revenir à mon problème, vous l’aurez compris : ma méthode GetObject() retournait à chaque fois un nouveau proxy vers le service WCF.
Résulat : à chaque fois que Spring avait besoin d’injecter mon proxy à une page (postback par exemple), je créai une nouvelle connexion au serveur WCF. J’ai fini par atteindre le nombre de connexion max, et le serveur ne répondait plus.

Il est tout de même dommage que les traces WCF ne m’ont pas révélé d’exception expliquant cette limite max de connexion

Pour approfondir le sujet sur les IFactoryObject :
Un objet qui implémente IFactoryObject doit toujours être un singleton, si ce n’est pas le cas on obtient une exception:

<object id="maFactory" type="MonAssembly.MaFactory, MonAssembly" singleton="false"/>

La propriété IsSingleton de la factory indique seulement ce qu’elle est censée faire… mais sans aucune obligation/vérification du comportement. Dans mon cas, je retournais true mais rien ne m’a empêché de créer une nouvelle instance à chaque appel…

Dans le cas particulier d’une application Asp.net, on peut avoir des “presque singleton” en changeant le scope:

<object id="maFactory" type="MonAssembly.MaFactory, MonAssembly" scope="application"/>

• scope=”application” : c’est un singleton de toute l’application web. Firefox et Safari m’affiche toujours 1.
• scope=”session” : c’est un singleton pour chaque session cliente. Firefox et Safari m’affiche toujours 2 (1 instance pour Firefox + 1 instance pour Safari).
• scope=”request” : c’est un singleton dans le cadre de la requête. Firefox et Safari vois le compteur s’incrémenter à chaque rafraichissement de la page.

Pour plus d’infos sur les scopes.

Conclusion(s) :

1. Ce n’est pas la propriété IsSingleton qui détermine si Spring va faire appelle une ou plusieurs fois à votre Factory. C’est à elle de fournir le comportement adéquat.
2. Un singleton n’en est pas toujours un… ça dépend du contexte. Dans tous les cas, pour éviter les erreurs comme la mienne, n’oublier pas d’utiliser la destroyMethod pour libérer les ressources. (l’interface ILifeCycle de Java n’existe pas encore dans Spring.net mais la 1.2 sort en RC1 début mai…).
3. Un “Timeout” peut vouloir dire “trop de connexion au serveur”
4. Cette fameuse Factory de proxy WCF sera fournie dans Spring.net 1.2. j’aurais perdu moins de temps en prenant les sources des nightbuilds… vive l’OpenSource!