Return to Question

I've been asked to do a small side-project to supply a simple application to one of our customers. Normally I would be working on back-end code where I have all of my testing needs figured out, and I've not yet had the dubious pleasure of writing tests for the GUI, so it's a little unclear to me how I should set up the testing code and tools for an EXE.

My first instinct was to simply include the tests with the application code, however that would require supplying a number of test-specific dependencies, which I have been instructed to specifically not ship to the customer. I am also unable to squeeze out any cash for a purpose built test tool, so I need to use the tools I have at hand (StoryQ, RhinoMocks, and NUnit), which really should be more than enough to test the behavior of a simple GUI app. So as far as I can see, this leaves me with trying to strike a good balance between keeping the design really simple, or purposefully over-engineering for the sake of the tests. It seems I'm either building the app with the business logic in a separate library and testing against the library as I usually would, or finding some other mechanism to allow me to the executable without breaking out additional modules that the application design doesn't really need.

Edit:
Please not that this question is about how to structure the relationship between NUnit and my executable - as opposed to a DLL - and not about how to separate presentation and business logic.
/Edit

So my question is:

1. Is there a specific/recommended method for configuring a simple GUI application with unit tests to allow me to adequately check state and behavior, using the tools I have at hand, and without resorting to over-engineering?
2. Have I missed something fundamental about the way NUnit should be invoked/configured when testing an EXE (as opposed to a DLL)?
3. Can you provide or point me in the direction of examples of how achieve all of this?

I realize that there may be more than one way to do this so I'm looking for specific implementation guidelines based on your experience.

I've been asked to do a small side-project to supply a simple application to one of our customers. Normally I would be working on back-end code where I have all of my testing needs figured out, and I've not yet had the dubious pleasure of writing tests for the GUI, so it's a little unclear to me how I should set up the testing code and tools for an EXE.

My first instinct was to simply include the tests with the application code, however that would require supplying a number of test-specific dependencies, which I have been instructed to specifically not ship to the customer. I am also unable to squeeze out any cash for a purpose built test tool, so I need to use the tools I have at hand (StoryQ, RhinoMocks, and NUnit), which really should be more than enough to test the behavior of a simple GUI app. So as far as I can see, this leaves me with trying to strike a good balance between keeping the design really simple, or purposefully over-engineering for the sake of the tests. It seems I'm either building the app with the business logic in a separate library and testing against the library as I usually would, or finding some other mechanism to allow me to the executable without breaking out additional modules that the application design doesn't really need.

Edit:
Please note that this question is about how to structure the relationship between NUnit and my executable - as opposed to a DLL - and not about how to separate presentation and business logic.
/Edit

So my question is:

1. Is there a specific/recommended method for configuring a simple GUI application with unit tests to allow me to adequately check state and behavior, using the tools I have at hand, and without resorting to over-engineering?
2. Have I missed something fundamental about the way NUnit should be invoked/configured when testing an EXE (as opposed to a DLL)?
3. Can you provide or point me in the direction of examples of how achieve all of this?

I realize that there may be more than one way to do this so I'm looking for specific implementation guidelines based on your experience.

I've been asked to do a small side-project to supply a simple application to one of our customers. Normally I would be working on back-end code where I have all of my testing needs figured out, and I've not yet had the dubious pleasure of writing tests for the GUI, so it's a little unclear to me how I should set up the testing code and tools for an EXE.

My first instinct was to simply include the tests with the application code, however that would require supplying a number of test-specific dependencies, which I have been instructed to specifically not ship to the customer. I am also unable to squeeze out any cash for a purpose built test tool, so I need to use the tools I have at hand (StoryQ, RhinoMocks, and NUnit), which really should be more than enough to test the behavior of a simple GUI app. So as far as I can see, this leaves me with trying to strike a good balance between keeping the design really simple, or purposefully over-engineering for the sake of the tests. It seems I'm either building the app with the main form in a module and testing against the module as I usually would, or finding some other mechanism to allow me to test as if my assembly was my usual run-of-the-mill DLL.

Edit:
While I realize that certain patterns such as MVP and MVVM can make the application more modular and thus easier to test, this question isn't about the specific architecture of the application per se, but rather about how to go about invoking tests when the target application is an executable and not a library.
/Edit

So my question is:

1. Is there a specific/recommended method for configuring a simple GUI application with unit tests to allow me to adequately check state and behavior, using the tools I have at hand, and without resorting to over-engineering?
2. Have I missed something fundamental about the way NUnit should be invoked/configured when testing an EXE (as opposed to a DLL)?
3. Can you provide or point me in the direction of examples of how achieve all of this?

I realize that there may be more than one way to do this so I'm looking for specific implementation guidelines based on your experience.

I've been asked to do a small side-project to supply a simple application to one of our customers. Normally I would be working on back-end code where I have all of my testing needs figured out, and I've not yet had the dubious pleasure of writing tests for the GUI, so it's a little unclear to me how I should set up the testing code and tools for an EXE.

My first instinct was to simply include the tests with the application code, however that would require supplying a number of test-specific dependencies, which I have been instructed to specifically not ship to the customer. I am also unable to squeeze out any cash for a purpose built test tool, so I need to use the tools I have at hand (StoryQ, RhinoMocks, and NUnit), which really should be more than enough to test the behavior of a simple GUI app. So as far as I can see, this leaves me with trying to strike a good balance between keeping the design really simple, or purposefully over-engineering for the sake of the tests. It seems I'm either building the app with the business logic in a separate library and testing against the library as I usually would, or finding some other mechanism to allow me to the executable without breaking out additional modules that the application design doesn't really need.

Edit:
Please not that this question is about how to structure the relationship between NUnit and my executable - as opposed to a DLL - and not about how to separate presentation and business logic.
/Edit

So my question is:

1. Is there a specific/recommended method for configuring a simple GUI application with unit tests to allow me to adequately check state and behavior, using the tools I have at hand, and without resorting to over-engineering?
2. Have I missed something fundamental about the way NUnit should be invoked/configured when testing an EXE (as opposed to a DLL)?
3. Can you provide or point me in the direction of examples of how achieve all of this?

I realize that there may be more than one way to do this so I'm looking for specific implementation guidelines based on your experience.

I've been asked to do a small side-project to supply a simple application to one of our customers. Normally I would be working on back-end code where I have all of my testing needs figured out, and I've not yet had the dubious pleasure of writing tests for the GUI, so it's a little unclear to me how I should set up the testing code and tools for an EXE.

My first instinct was to simply include the tests with the application code, however that would require supplying a number of test-specific dependencies, which I have been instructed to specifically not ship to the customer. I am also unable to squeeze out any cash for a purpose built test tool, so I need to use the tools I have at hand (StoryQ, RhinoMocks, and NUnit), which really should be more than enough to test the behavior of a simple GUI app. So as far as I can see, this leaves me with trying to strike a good balance between keeping the design really simple, or purposefully over-engineering for the sake of the tests. It seems I'm either building the app with the main form in a module and testing against the module as I usually would, or finding some other mechanism to allow me to test as if my assembly was my usual run-of-the-mill DLL.

So my question is:

1. Is there a specific/recommended method for configuring a simple GUI application with unit tests to allow me to adequately check state and behavior, using the tools I have at hand, and without resorting to over-engineering?
2. Have I missed something fundamental about the way NUnit should be invoked/configured when testing an EXE (as opposed to a DLL)?
3. Can you provide or point me in the direction of examples of how achieve all of this?

I realize that there may be more than one way to do this so I'm looking for specific implementation guidelines based on your experience.

I've been asked to do a small side-project to supply a simple application to one of our customers. Normally I would be working on back-end code where I have all of my testing needs figured out, and I've not yet had the dubious pleasure of writing tests for the GUI, so it's a little unclear to me how I should set up the testing code and tools for an EXE.

My first instinct was to simply include the tests with the application code, however that would require supplying a number of test-specific dependencies, which I have been instructed to specifically not ship to the customer. I am also unable to squeeze out any cash for a purpose built test tool, so I need to use the tools I have at hand (StoryQ, RhinoMocks, and NUnit), which really should be more than enough to test the behavior of a simple GUI app. So as far as I can see, this leaves me with trying to strike a good balance between keeping the design really simple, or purposefully over-engineering for the sake of the tests. It seems I'm either building the app with the main form in a module and testing against the module as I usually would, or finding some other mechanism to allow me to test as if my assembly was my usual run-of-the-mill DLL.

Edit:
While I realize that certain patterns such as MVP and MVVM can make the application more modular and thus easier to test, this question isn't about the specific architecture of the application per se, but rather about how to go about invoking tests when the target application is an executable and not a library.
/Edit

So my question is:

1. Is there a specific/recommended method for configuring a simple GUI application with unit tests to allow me to adequately check state and behavior, using the tools I have at hand, and without resorting to over-engineering?
2. Have I missed something fundamental about the way NUnit should be invoked/configured when testing an EXE (as opposed to a DLL)?
3. Can you provide or point me in the direction of examples of how achieve all of this?

I realize that there may be more than one way to do this so I'm looking for specific implementation guidelines based on your experience.