I'd think you should be writing "stub" routines for your eventual "perform some bit of database work using these parameters, examine the result(s), return info to app or raise an exception" routines, (Such routines don't always have to be implemented by calling SPs.) Those "stub" routines should accept the same parameters that the real routines will accept, and should return properly formed simulated results (a dataset is a very flexible beast), and should perhaps raise an exception some percentage of the time. (If the stubs never raise an exception, how will you test your error handling?)
Sometimes the data returned from the database will be getting a result-set, sometimes just a return-code, sometimes both; you might get multiple result-sets in some cases. How will the rest of the app continue if it doesn't get realistic results to process from the app-level routine that talks to the database (whether via stored proc or not)? I wonder why you want to send info over the network, and get it back over the network, to simulate sending data to, and receiving it back from, the database? Your app won't process a TDS stream directly -- I would hope -- so why are you trying to simulate "call the database" at that level of detail? How will you know if the correct data is being sent out, if you don't have something that actually processes it? How will you know that the code is processing result(s) in the form that will actually being returned? At 08:05 AM 1/8/2004, SteveC wrote >No, because MSDE would require me to install the database and start to write >TSQL. I don't want to do that. I am thinking about a .NET assembly that >will pretend that it is a real database and return a TDS stream, while it is >actually not. Something that would listen on the actual SQL server ports, >accept parameters, and return some data just like SQL Server does; but it >could live on a developer's system without requiring a full database load. > >My development cycle typically includes tiered coders, each are given an >explicit document of "what to do", even in calling stored procedures. The >problem is that all of the stored procedures are not ready or written (or >sometimes fully thought out and need to be changed) on the DB side of >things. So it would be to the .NET component developer's advantage to have >the DB-calling code in place, but instead of calling the real thing, it just >calls this pseudo-MSSQL-host. Then the .NET coders could perform unit >testing and etc without having things break when they are actually supposed >to get data from "somewhere". >[snip] J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
