2009-09-11 10 views
1

J'ai configuré un serveur de build TFS 2008 64 bits avec Sharepoint, une intégration continue et un MSTest prêt à l'emploi. Les tests unitaires pour les classes de logique métier simples fonctionnent parfaitement et les résultats des tests sont publiés dans TFS. Cependant, tout test utilisant l'API Sharepoint échoue horriblement, SPFarm.Local renvoie null et ainsi de suite. Y'a t'il un moyen d'arranger cela? Les tests s'exécutent correctement dans un environnement de développement 32 bits par ailleurs identique (Windows Server 2008 sous Hyper-V, Sharepoint corrigé jusqu'à la mise à jour cumulative de juin 2009) à partir de Visual Studio et de la ligne de commande. l'utilisation de SPContext.Current ou de toute autre partie de l'API qui doit être exécutée dans un contexte de serveur Web. J'ai exclu permissions issues, car le compte de l'agent de build peut déployer la solution et créer des collections de sites très bien avec stsadm. Le prochain coupable pourrait être que les tests unitaires étaient exécutés avec un 32-bit process, qui ne pouvait pas accéder correctement à l'API Sharepoint 64 bits. J'ai essayé a workaround, mais il a l'effet secondaire de désactiver le support de TFS dans MSTest. Est-ce que je dois attendre les versions 2010 des outils MS (et espérer le meilleur) ou existe-t-il un framework de test tiers fonctionnant nativement en 64 bits et pouvant publier les résultats des tests dans TFS 2008?Intégration continue avec Sharepoint 64 bits et TFS 2008?

Répondre

0

Je viens de rencontrer moi aussi ce problème. Après avoir chassé sur le net, j'ai finalement trouvé cet article: http://fastrup.net/post/Visual-Studio-Unit-Tests-and-64-bit-SharePoint-does-not-play.aspx

Je me penchais déjà en direction de NUnit pour voir si cela ferait une différence, et maintenant je vais explorer cette avenue et si ça marche ce sera mon approche. C'est frustrant quand vous voulez faire la bonne chose et que l'unité teste tout ce que vous faites mais les outils ne supportent pas l'environnement dans lequel vous devez travailler.

+0

Suite à cela. Après avoir utilisé NUnit pendant une semaine sur mon projet SharePoint actuel, je suis vendu. Tout fonctionne comme je le souhaite, et je n'ai encore rencontré aucun obstacle. La seule chose supplémentaire que je voudrais est d'être en mesure d'engager le débogueur sur les tests de NUnit. Je suis sûr qu'il y a un moyen, cependant, je ne l'ai pas encore trouvé. –

2

Cela se produit car SharePoint n'a aucun contexte dans les tests en cours d'exécution. Le contexte de SharePoint (en particulier en pensant à l'objet SPContext.Current ici) n'est rempli que lorsqu'il est exécuté dans une page ASP.NET dans le cadre d'une requête HTTP. MSTest ne fait pas ça.

Si vous devez effectuer des tests d'intégration (distincts des tests unitaires) par rapport à l'API SharePoint, vous pouvez utiliser Typemock Isolator for SharePoint. Cela se moquera de ces objets SharePoint afin qu'ils ne soient plus null. Voir Francis Cheung's blog pour un exemple.

Modifier après le commentaire: Je n'ai pas d'expérience directe avec cela, mais je ne vois pas pourquoi il y aurait un problème entre 32 bits et 64 bits. Veuillez regarder de près les différences d'environnement et de configuration.

+0

+1 pour la référence Typemock Isolator for SharePoint. J'ai commencé à chercher dans cet outil myslef récemment. – Colin

+0

Les tests n'utilisent pas SPContext.Current et n'utilisent aucune partie de l'API qui utilise SPContext en interne (comme dans ma précédente question sur PortalSiteMapProvider). Les tests s'exécutent très bien dans un environnement 32 bits identique. – Hirvox

+0

@Hirvox: D'accord, vous ne l'avez pas mentionné dans votre question. Il pourrait s'agir d'une chose 64 vs 32 bits, mais je suppose qu'il y a une différence dans l'environnement/config. –

Questions connexes