7/6/2025 6:28:52 AM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss the use of the SalesLogix Web Platform, Client and Customer Portals, and the Application Architect (For version 7.2 and higher only). View the code of conduct for posting guidelines.
|
|
|
|
Testing best practices
Posted: 13 May 09 12:14 AM
|
Anyone have advice and best practices they are willing to share regarding testing SLX Web 7.5+? Both testing that customizations are all working and that new changes haven't broken anything, and performance testing - how will the deployed application perform under various loads?
TDD doesn't seem to be part of the SLX development culture but maybe I'm missing it.
Any advice out there?
Thanks,
Doug |
|
|
|
Re: Testing best practices
Posted: 14 May 09 3:35 AM
|
Hi Doug,
Just asking, have you already installed the Application Achitect and done the website configurations on your local machine?
Can you give some indication how far you have got already?
|
|
|
|
Re: Testing best practices
Posted: 14 May 09 10:15 AM
|
As you wrote, TDD is not really part of the culture at this time. However it is quite possible to get your business rules into a test harness and test them with NUnit. I have not tried web testing tools like Watin and such yet but I suppose it would be possible to use those also.
Would be interested to know what you end up setting up for automated testing. |
|
|
|
Re: Testing best practices
Posted: 14 May 09 10:38 AM
|
Hi Derek,
I've got AA installed and working and have been making customizations left and right (business rules, c# snippets, changes to quickforms, custom forms, etc) and am getting nervous that with all of this far-flung customization I have little confidence that I can be sure everything still works after making further changes. Ideally, testing would be part of development, I guess, such that tests are baked-in from the start. At this point I'm just wondering how folks out there are automating their testing process, if at all. Currently mine is entirely manual and the project I'm working on is getting too large to be confident I've got it all covered. In the end the users function as testers. That's not good.
-Doug |
|
|
|
Re: Testing best practices
Posted: 15 May 09 1:41 AM
|
Hi Doug,
Ok, so by the sounds of it you have done a lot. As far I know there is no automated testing. Also it recommended that before you start, or whilst doing customizations that a back up of your "VFS Model" is done every now-and-again. Have you been doing that thus far? If you have that is great.
As far as testing goes it is all manual, the way I do testing is have everything first setup on a development PC and use the local Inranet to see if what I have done works (make sure that your IIS is setup). Then bundle to use on the production system.
Another recommended tool is SVN (for free on the internet) you can use this (safe) tool, much like Source Safe, Where changes you make to local VFS Model are identified then when you "Commit" the progam updates a "suppossitry" which you can use to update the production VFS model. This way your previous work is not over written and only changes you have done are added to the VFS Model.
If you are finding that testing and deploying is rather slow another suggestion is whilst doing your customizations,etc switch off antivirus software, and services not been used during this time.
I hope this helps?
|
|
|
|
Re: Testing best practices
Posted: 15 May 09 6:08 PM
|
Well, to me automated testing of the business rules is the #1 advantage of the platform. It is not built-in, but not too hard to set up. I can share the test harness I am using if there is interest.
Also, this was effectively impossible in previous versions of Saleslogix. So it is a huge leap ahead for TDD proponents.
Automated testing of the UI might be possible but would probably involve a lot more effort. |
|
|
|
Re: Testing best practices
Posted: 16 May 09 1:12 AM
|
Nicolas,
I for one am interested in the test harness you are using and any other info you care to share about your approach to testing business rules.
You mentioned Watir for automated UI testing - have you tried it? Any others?
-Doug |
|
|
|
Re: Testing best practices
Posted: 19 May 09 8:10 AM
|
Sure - it really works pretty well for me and is quite simple. I put all business rules in an external assembly so that I can edit them and test them in Visual Studio. I then create a separate assembly that contains the unit tests. I create a SetupFixture (I use NUnit) with the following code:
[SetUpFixture]
public class TestSuiteSetup
{
SlxAppSetup _setup;
[SetUp]
public void Setup()
{
_setup = new SlxAppSetup(@"E:\Projects\SlxEval\www\SlxClient", "");
_setup.Open();
}
[TearDown]
public void Teardown()
{
_setup.Close();
}
}
The SlxAppSetup class is a helper class I wrote to help with copying the business rules assemblies from the web deployment folder to the execution path, and setting up the various globals and service configurations that Saleslogix need. You can download it from http://blog.chivinou.net/media/SlxAppSetup.cs and use it as is if you wish. I ripped it from a larger project, I don't think it has any external dependencies but let me know if you try compiling it and have a hard time. It is also possible to use it in a 3rd party application (outside of the web client) though I have not done so for actual production apps yet. A unit test class may then look something like (hopefully this formats OK through the forum):
[TestFixture]
public class TestSEOpportunityExtRules
{
[Test]
public void TestProductsAndUtilitiesRemovedWhenStateChanges()
{
using (DBConnectionWrapper db = new DBConnectionWrapper("Default"))
{
String oppId = (String)db.GetField("OPPORTUNITYID", "OPPORTUNITY_EXT", "STATE IS NOT NULL AND OPPORTUNITYID IN (SELECT OPPORTUNITYID FROM OPPORTUNITY_PRODUCT) AND OPPORTUNITYID IN (SELECT OPPORTUNITYID FROM UTILITY)");
using (var tx = new TransactionScope())
{
IOpportunity opp = EntityFactory.GetById(oppId);
Assert.Greater(opp.Products.Count, 0);
Assert.Greater(opp.SEOppUtilities.Count, 0);
String oldState = opp.SEOpportunityExt.State;
String newState = (oldState == "PA" ? "NJ" : "PA");
opp.SEOpportunityExt.State = newState;
opp.Save();
Assert.AreEqual(0, opp.Products.Count, "Products should be removed when state changes");
Assert.AreEqual(0, opp.SEOppUtilities.Count, "Utilities should be removed when state changes");
tx.VoteRollback();
}
}
}
}
DBConnectionWrapper is another helper I wrote to wrap data access - but you can use good old ADO.NET there with the ConnectionStringDataService as well. ApplicationContext.Current will be available to retrieve services though not all services that are available on the web client will be available - only the bare minimum (also some services are replaced with a mock service, for example UserService always returns ADMIN).
I usually wrap the test with a TransactionScope and roll it back at the end but for some tests (e.g. if you need to test a BeforeUpdate event) you need to actually commit the transaction to get the event to trigger.
It does take a little bit to set up but the ability to develop rules without having to test them through the web client UI is priceless! I see it being a big advantage during upgrades too as it will help point out the places where I am relying on API that no longer work the same way.
I have not tried Watir very seriously yet. A year ago I looked at Watir, Watin and Selenium and while interesting they all seemed to involve a bit too much setup to be worthwhile for the project I was working on at the time - however with the slow startup time of the 7.5 web client I am tempted to revisit this... Manual testing is tedious because of the long wait time the first time a page is accessed.
Hope this helps you get started - I think unit testing offers a huge benefit to quality of code and long-term development costs and I feel now for the first time we have the opportunity to make it an integral part to Saleslogix development. |
|
|
|
Re: Testing best practices
Posted: 25 May 09 10:55 AM
|
Thanks for this! I haven't implemented business rules as external assemblies but it looks like it would be worth the trouble to do so in order to be able to test them more easily. Do you have any advice about doing so - or "gotchas" to avoid?
I've taken notice of Windmill (http://www.getwindmill.com/) - any experience with it? I may give it a try. |
|
|
|
Re: Testing best practices
Posted: 25 May 09 5:10 PM
|
In general I have found that I had an easier time implementing the rules as external assemblies. You get a better editor, faster compilation, and the problems that you encounter will be .NET idiosyncrasies, rather than Application Architect ones, thus it is a lot easier to find support for them. You need a way to easily copy the assemblies you create to the web site (I open my web site in Visual Studio, then add my project containing the business rules as a reference, this way it is copied automatically) and a way to copy them to the "Support Files" area of the Saleslogix project so that they can be integrated with your bundles etc (I have a small batch file using robocopy to copy all my custom smart parts and assemblies back to the Support Files area). The basic thing you need to know is:
* in app architect when you define a rule you will tell it the name of the assembly to find it in, not the location of that assembly on the disk
* at runtime ASP.NET is going to look for that named assembly in its "bin" folder, so that is where it will need to be
I had not heard of Windmill but might try it out to see if it easier to use than selenium / watir. |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|