|
There seems to be more than quite a few docs out there that teach you how to do TDD from scratch, but I haven't seen much theoretical work done on "mocking out" and testing existing components from legacy apps--for example, if I have a DAL that's already plugged into my four-year old .NET 1.1 app, is there anyway I can apply post-hoc unit tests to the DAL without changing its design?
What I'm really looking for is a catalog of "mocking patterns" that give me solutions to various problems so that I can isolate my legacy components and test them without modifying the design--so my question is, has anyone managed to do this yet?
|
|
|
|
|
|
About NMock / NMock2:
the version at nmock.org (NMock) is not actively supported anymore.
If you are looking for the latest version based on NMock then have a look at https://sourceforge.net/projects/nmock2[^] (NMock2)
Happy mocking
Urs
-^-^-^-^-^-^-^-
no risk no funk
|
|
|
|
|
Hrmmm I'd be assuming you are kinda boned in that case without some real trickery. Most legacy code of this kind I've seen tends to be fairly rigid - definitely no dependancy injection or even factory patterns. It sounds hard.
Possibly you could do something like post-process the compiled DAL, and replace instantiations of certain classes with your mocked instances, and then run the tests. :S
|
|
|
|
|
Mark Churchill wrote: Hrmmm I'd be assuming you are kinda boned in that case without some real trickery. Most legacy code of this kind I've seen tends to be fairly rigid - definitely no dependancy injection or even factory patterns. It sounds hard.
Without a doubt, it is incredibly difficult--you'd have to find a way to isolate the target component and then "extrude" it so that you can test its behavior without pulling it completely out of a compiled assembly--in essence, it's like refactoring in reverse--albeit in a binary form.
It's definitely a black art, to say the least.
Mark Churchill wrote: Possibly you could do something like post-process the compiled DAL, and replace instantiations of certain classes with your mocked instances, and then run the tests. :S
Actually I'm not too worried about how to replace the classes or methods with mocks--what I'm really looking for is a a common set of testing practices that I can programmatically apply to the portion of legacy code that I want to test. Based on the lack of responses to this thread, however, I can only surmise that there aren't that many people out there that specialize in applying automatic regression tests to legacy code without changing the design--so for now it's more of a pipe dream, but I'll have a lot of fun making it a reality. Thanks for the input, Mark!
|
|
|
|
|
Have you looked into Pex[^]? It's an interesting concept, to say the least.
|
|
|
|
|
Pete O'Hanlon wrote: Have you looked into Pex[^]? It's an interesting concept, to say the least.
From what I can tell, Pex looks like a brute-force solution to unit testing--it solves some of the coverage problems in TDD by attempting to quantify every possible input and output that might come out of a single method. There's two problems to this approach: 1) Observability, and 2) Isolating the component to be tested.
The first problem of observability has a lot to do with the software engineering equivalent of the Uncertainty Principle--how do you observe the behavior of an app without having to modify it? For example, if I wanted to test the DAL of a legacy app and that application has a tightly-coupled architecture, how do you verify the behavior of the DAL without modifying its architecture to support unit testing? With Pex, you can only test the components of an architecture if their behavior can be "observed" by the unit tests generated by Pex; however, in a legacy app, you might not have the luxury of modifying the architecture to support those unit tests.
The isolation problem rears its ugly head when you have legacy code that is ridden with "copy & paste" code. In order to use automated unit testing (much less Pex), you would have to refactor out the duplication and then mock out the components around the component to be tested, and then test the component itself. Once you have the component isolated, it is then (and only then) that you can throw Pex at it and have it do its brute-force approach to finding holes in your code.
The problem with using Pex with legacy apps is that the approach might be too invasive. In the current state of automated unit testing and TDD, this is akin to giving bypass surgery to a patient who just wants a medical checkup. What I want to do is diagnose the patient (per se) without killing them in the process. IMHO, we're practically in the Dark Ages when it comes to diagnosing legacy apps, and that has to change.
|
|
|
|
|
If you need to unit test legacy code, code that isn't particularly designed for mockability (or isn't designed for it at all), there is nothing that comes close to the TypeMock Isolator. TypeMock lets you mock absolutely anything, any time, for any reason, regardless of what it is. You can mock statics, replace function calls, whatever you need to. It allows you to fully isolate your unit of interest and actually perform "unit" testing for any code, regardless of whether it actually supports unit testing.
Many people will jump on this with a vehement revulsion and provide blanket statements that you should refactor all of your code so its better architected and is properly mockable. In the long run, yes, you should eventually improve your code base. But when your on a budget and need that full safety net of tested code, TypeMock is a godsend. You can, basically, have your cake and eat it too. I hope it helps. 
http://www.typemock.com/
|
|
|
|
|
You're right - I am going to jump on this post. In fact, I'm going to jump all over it and say - interesting, I'll go and have a look at it now.
|
|
|
|
|
LOL, let me know what you think.  I'm still evaluating it myself, but and it does have a couple drawbacks (i.e. the isolator is a 'wrapper' program that must be running for method intercepts and the like to function during execution, and it costs money). When it comes to testing locked-down legacy code, though, its truely unique.
|
|
|
|
|
Class A
{
B bsObject;
public void FunctionOfClassA()
{
bsObject.FunctionOfClassB()
}
}
Class B
{
public void FunctionOfClassB()
{
}
}
I have my program structure as shown above.
I want a way to apply atomicity to this. I mean if Class B's data write worked fine but Class A's calculations failed then want to rollback the data write. i want it all succeed or rollback.
One way i can think of is to create a DB ptr and begin transaction just before call to FunctionOfClassB() and pass it as a parameter. so in this FunctionOfClassB will use same db ptr to write data. And it would also be possible in FunctionOfClassA() to check if calculations went ok then commit or rollback.
My requirement is to not to make any change in parameter list or not to provide a new method with new parameter.
Class A
{
B bsObject;
public void FunctionOfClassA()
{
bsObject.FunctionOfClassB()
// some calculations
// Here I want to decide whether to commit or rollback
}
}
Class B
{
public void FunctionOfClassB()
{
// here i want to begin a transaction
// some data writing.
}
}
Can anyone give an high level summary how this could be possible?
|
|
|
|
|
paresh_joe wrote: I want a way to apply atomicity to this.
this? The code you posted has no data, there are no write operations, therefore nothing to roll forwards or backwards, even sideways. 
led mike
|
|
|
|
|
paresh_joe wrote: My requirement is to not to make any change in parameter list or not to provide a new method with new parameter.
If so as above, then how can you (down below) pass the pointer since your function accepts no parameters in your skeleton class.
paresh_joe wrote: One way i can think of is to create a DB ptr and begin transaction just before call to FunctionOfClassB() and pass it as a parameter.
Please reword.
|
|
|
|
|
I meant to say that only solution come to my mind is to pass DB parameter to function which is not possible. I want some other way in which this can be implemented.
|
|
|
|
|
Can the server function throw an exception if transaction is not completed? Yes, then you can handle it in the client and do whatever you need to. Another approach is, if you can, to introduce two events in the server method which can be raised when the server method either completes or fails. This event will have one parameter derived from the EventArgs class (if using .NET) and it can contain information about what happened during the transaction--what failed and what passed.
What do you think?
|
|
|
|
|
I REALLY DONT KNOW.........PLS HELP
|
|
|
|
|
I don't understand what you are asking. You are back after a long time! Can you be more clear about your question?
CodingYoshi
Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07
|
|
|
|
|
|
|
|
|
Current Scenario:
I have a long running application that gets a job list from sql, creates a child process for each request and exchange status data with those child process with a full-duplex communication.
All processes runs on the same machine as the host application, currently all processes are Win32 and I use WM_COPYDATA.
Future:
It is likely that in the next future the Win32 application will be rewritten to .NET, child processes will remain untouched, new child processes will be written in any language/platform (.NET, Win32) depending on 3rd party specifications/libraries.
Question:
I would like to hear some rant on how to implement interprocess communication between .NET and Win32 application.
TIA
|
|
|
|
|
You could convert the WM_COPYDATA-solution to a C#-counterpart. Windows-messaging is fast, and you'd retain compatibility with the old version.
Alternatively you could use a HttpServer, and use WebRequests; easier to debug than Windows-messages, and you can send/receive messages from beyond the local desktop.
I are troll 
|
|
|
|
|
This is a simple class I am building to abstract some functionality. Pay attention to my use of assertions.
///
/// Encapsulates execution of queries.
///
public class QueryExecutor
{
/// summary
/// Returns a DataTable object populated using the specified parameters.
/// summary
/// param name="connectionString" // the connection string to use
/// param name="queryType" //
/// param name="queryText"
/// returns
public static DataTable GetTable(string connectionString, CommandType queryType, string queryText)
{
Trace.Assert(queryText != null, "QueryExecutor::GetData\nQuery must not be null.");
Trace.Assert(queryText != string.Empty, "QueryExecutor::GetData\nQuery must not be empty.");
Trace.Assert(connectionString != null, "QueryExecutor::GetData\nConnection must not be null.");
Trace.Assert(connectionString != string.Empty, "QueryExecutor::GetData\nConnection must not be empty.");
SqlConnection connection = new SqlConnection(connectionString);
SqlCommand query = connection.CreateCommand();
query.CommandType = queryType;
query.CommandText = queryText;
SqlDataAdapter adapter = new SqlDataAdapter(query.CommandText, connection);
DataTable table = new DataTable();
try
{
adapter.Fill(table);
}
catch (SqlException)
{
ReleaseResources(adapter, connection);
throw;
}
catch (Exception)
{
ReleaseResources(adapter, connection);
throw;
}
return table;
}
private static void ReleaseResources(SqlDataAdapter adapter, SqlConnection connection)
{
adapter.Dispose();
if (connection.State == ConnectionState.Open)
connection.Close();
}
}
I am trying to fully understand the difference between assertions and exceptions. According to readings I have read, I have come to conclusion that assertions are used for errors which should never occur and thus programmers can fix it, and for class invariances. In other words it warns the programmer and helps the programmer know that the code is actually doing what it was intended to do. Exception on the other hand can not be fully avoided but they can be anticipated and gives the opportunity to deal with it somehow during runtime. For example, if the application is trying to read a file from a path provided by the user and the file does not exist, the programmer can not really do anything but throw exception and application will handle it. Then application will tell the user that file does not exist.
My questions now are:
1. In my class above, according to my understanding which I explained above, the programmer should give me a connection string at least, therefore, I am asserting that connection string can not be empty or null. This is an error which should never occur so I am using assertion instead of throwing exception. Is this ok? Wow...I just came up with a thought (funny how when you are asking a question you come up with more questions): What if the caller is reading the connection string from a file and sending it over, now I am not giving the caller the opportunity to handle the error and try again or something. But still the caller should at least verify that the string is not empty or null.
2. Another question is why should I use Trace and not Debug apart from the known fact that Trace is bundled up with release versions but Debug is not.
3. What else is wrong with my style of coding? I know it needs more work to handle TableDirect or simple query.
4. Any other suggestions?
Thanks,
|
|
|
|
|
Have a google for "Design by Contract" and "nContract".
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
