Recently I had a .Net application dumped in my lap; that is, I was forced to understand it, the server on which it resides, and the code it is comprised of.
I was petrified. A good part of being a good tester is understanding completely every nut and bolt that goes into what you are testing. How else can you set expectations? There can be no ambiguity.
What I found after a week or so is that my fears were (largely) unfounded. Once you get past some basic issues on web hosting and syntax issues it's pretty simple.
How do I put this? Hmmm. Once you put your Fox-brain aside and truly evaluate non-Fox project architecture and syntax you will realize just how clueless 90+% of these folks are. Once I understood the mechanics enough to assess the underpinnings I was struck by the realization that the average .Net developer may be much more addled on delivering a "best practices" solution than your average VFP developer.
This goes back to my assertions 5 years ago on the UT and elsewhere that the VFP community has (had?) a tremendous opportunity as architects to embrace the .Net way of life and kick-ass. I am more convinced as ever of this after the stuff I've had to go through the past few weeks.
Some of y'all know and embrace this already. Strahl and McNeish come to mind...
Forget translating apples to oranges and applying VFP architecture to .Net and the Web. Just look at what .Net and the framework has to offer and how you would approach a client solution at a high level.
The light will come on. And you'll be thinking, "Holy shit, why did I ever think this was hard?" Sure, sure you'll still be thinking (as I do) that there are far easier ways to do x, y, and z in VFP (and that's true) but if you get off of trying to decode every line of code you'll see it.
Go forth my VFP brethren and kick the .Net coders, who have far less experience in the real world as you do, in the teeth.