I am very new to all that is NUnit. I have been tasked with exploring NUnit for use in testing some existing applications.
My Question is: How can I test a winforms datagrid's "content" as well as the "doublclick" event using NUnitForms?
i.e. dgSearchResults.Rows(0).Cells(0).value, for instance... And the row doubleClick event
I was successfully able to create this in NUnitAsp with the datagridtester that is supplied with NUnitAsp; but there doesn't seem to be any discussion of this for NUnitForms.
Do I need to create my own control tester?
By the way, I have researched and tried to use the controlTester method with no luck. But, to get around the doubleClick event in the meantime, I have used the mouse.UseOn and mouse.DoubleClick(x,y) methods. But this is just a work around.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I replied to a couple of recent forum messages recently directly rather than to the forum, so this late reply is really for the benefit of the forum.
I don't think this is going to be the sort of answer your looking for but it raises some good questions. I've had the same problem with testing datagrids it is not straight forward. But before we go there maybe the best answer is "don't". It comes down to what do you mean by "test".
By "test" do you mean "unit tests"? If so, why test a .Net control? What you really want to test is the code you have written and then, later, you may want to write a "User Acceptance Test" (UAT) that tests the user behaviour of the running application. Despite its name NUnitForms is really a tool to develop a framework for UATs and is, inherently, no a unit test tool as it works on .Net framework controls.
So, (talking "unit tests") you are writing code and want an automated way to test it. Then assume that the DataGrid works and test the data you are passing the datagrid. If your using binding then just test the collection you are binding to. The Model View Control (MVC) pattern is very good for this.
But if you want to do an integration or UAT then the issue is that the values displayed may come from a formatter (override format events) or from the grid using ToString on object values. In a general sense there is not way of reading from the datagrid what was displayed as ... well ... it may not know as a formatter did it.
If you are writing code take the unit test approach and leave NUnitForms alone for now. If you are not writing code right now but need to test end application functionality (UAT) then pick up NUnitForms and start developing a domain specific language to test your app. Your framework will need to take some shortcuts to test the DataGrid and these will depend on your architecture, MVC, formatters, binding, etc.
Rob Smyth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>>Despite its name NUnitForms is really a tool to develop a framework for UATs and is, inherently, no a unit test tool as it works on .Net framework controls.
I understand what you are saying here. However I really did intend it as a tool to help with unit testing. It lacks much of what people would need for UAT (now, perhaps it could grow)
I originally intended to test 2 things with it.
The first is the minimal code that belongs in the code behind file. (perhaps event wiring and data binding.) The way the designer worked with code behind made it hard to unit test "code behind methods" that manipulate or respond to .NET controls in isolation from those controls. See the sample project code for an oversimplified example of this. I tried to minimize the code in the code-behind, but still test it. There are likely better ways to do this / I haven't worked a lot with these things since '04.. (How many people are mocking out their control layer?)
The 2nd intended use was for testing controls that are written by the user.. not framework provided controls.. (That is where the mouse / keyboard would be possibly more useful..)
For example, in order to test that a button is disabled, I would have said you should assert that control.Enabled == false after invoking the code that would disable it. With mocks, you could assert that "control.Enabled = false" was called, but it is less easy to mock out framework controls manipulated from the code behind during databinding..
Hope this makes a little sense (I am not taking enough time to make it concise) Of course everyone is free to make of the tool what they wish..
Luke
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Specifically, what I'm trying to do is test an application that is complete. I am not the developer of that application so I don't have rights to edit the application project files. In the future, we'll try to follow more of a TDD approach, but we aren't there yet.
I have some scenarios that involve business rules that I am trying to test with NUnitForms. For instance, if a record has a specific field populated, control x is disabled. Or, if you try to edit a record that is past status z then you get a message that says "xyz".
So, the way we edit a record in this application is by double clicking the row of the record in the data grid that you want to edit. Then a modal form opens with all the fields for that record and those fields need to be tested.
This is the scenario I have to test. Surely, this is a common issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, this sounds like classic UATs. Yes, I think this is a common issue as our team hit this too. Thing is the datagrid holds objects, how they are displayed is another matter. No brainer if the object is a string or Int etc but if it is a custom class or if you add a formatter then the datagrid is not determining what is displayed. e.g. Icon, colour, or just plain old text.
So, for a datagrid we had to get dirty and actually get the object from the grid control. This means you actually have to know about the object. Yea, real nasty. Maybe somebody has a great solution but to my knowledge the DataGrid formats dynamically and does not hold a record of what is displayed for each cell :-(.
Rob Smyth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My thinking is that NUnitForms is a framework for UATs and that is its future. A good future as there is a big need. I cannot see how NUnitForms can be used for "unit testing" as it inherently deals with .Net controls so the closest it could get is to do "integration tests".
The team I'm on does separate all controls to a thin 'view' which is basically just the designer generated form. We put an interface on this an mock it for all unit tests. When we need to pass a class like 'Control' into our code we wrap it into another class (Resharper can do this automatically for you) so we can get an interface ... and yep then mock it. The rule is that the only concrete class instantiated in a unit test is the class under test.
We use NUnitForms as the framework of a domain specific language for our application UATs. We use NUnit and NMock2 for our unit tests.
I recon NUnitForms has a great future pushed as a UAT rather than unit test framework.
See ya
Rob Smyth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also posted this in the NUnit forum.
I am very new to all that is NUnit. I have been tasked with exploring NUnit for use in testing some existing applications.
My Question is: How can I test a winforms datagrid's "content" as well as the "doublclick" event using NUnitForms?
i.e. dgSearchResults.Rows(0).Cells(0).value, for instance... And the row doubleClick event
I was successfully able to create this in NUnitAsp with the datagridtester that is supplied with NUnitAsp; but there doesn't seem to be any discussion of this for NUnitForms.
Do I need to create my own control tester?
By the way, I have researched and tried to use the controlTester method with no luck. But, to get around the doubleClick event in the meantime, I have used the mouse.UseOn and mouse.DoubleClick(x,y) methods. But this is just a work around.
Hi,
I replied to a couple of recent forum messages recently directly rather than to the forum, so this late reply is really for the benefit of the forum.
I don't think this is going to be the sort of answer your looking for but it raises some good questions. I've had the same problem with testing datagrids it is not straight forward. But before we go there maybe the best answer is "don't". It comes down to what do you mean by "test".
By "test" do you mean "unit tests"? If so, why test a .Net control? What you really want to test is the code you have written and then, later, you may want to write a "User Acceptance Test" (UAT) that tests the user behaviour of the running application. Despite its name NUnitForms is really a tool to develop a framework for UATs and is, inherently, no a unit test tool as it works on .Net framework controls.
So, (talking "unit tests") you are writing code and want an automated way to test it. Then assume that the DataGrid works and test the data you are passing the datagrid. If your using binding then just test the collection you are binding to. The Model View Control (MVC) pattern is very good for this.
But if you want to do an integration or UAT then the issue is that the values displayed may come from a formatter (override format events) or from the grid using ToString on object values. In a general sense there is not way of reading from the datagrid what was displayed as ... well ... it may not know as a formatter did it.
If you are writing code take the unit test approach and leave NUnitForms alone for now. If you are not writing code right now but need to test end application functionality (UAT) then pick up NUnitForms and start developing a domain specific language to test your app. Your framework will need to take some shortcuts to test the DataGrid and these will depend on your architecture, MVC, formatters, binding, etc.
Rob Smyth
>>Despite its name NUnitForms is really a tool to develop a framework for UATs and is, inherently, no a unit test tool as it works on .Net framework controls.
I understand what you are saying here. However I really did intend it as a tool to help with unit testing. It lacks much of what people would need for UAT (now, perhaps it could grow)
I originally intended to test 2 things with it.
The first is the minimal code that belongs in the code behind file. (perhaps event wiring and data binding.) The way the designer worked with code behind made it hard to unit test "code behind methods" that manipulate or respond to .NET controls in isolation from those controls. See the sample project code for an oversimplified example of this. I tried to minimize the code in the code-behind, but still test it. There are likely better ways to do this / I haven't worked a lot with these things since '04.. (How many people are mocking out their control layer?)
The 2nd intended use was for testing controls that are written by the user.. not framework provided controls.. (That is where the mouse / keyboard would be possibly more useful..)
For example, in order to test that a button is disabled, I would have said you should assert that control.Enabled == false after invoking the code that would disable it. With mocks, you could assert that "control.Enabled = false" was called, but it is less easy to mock out framework controls manipulated from the code behind during databinding..
Hope this makes a little sense (I am not taking enough time to make it concise) Of course everyone is free to make of the tool what they wish..
Luke
Specifically, what I'm trying to do is test an application that is complete. I am not the developer of that application so I don't have rights to edit the application project files. In the future, we'll try to follow more of a TDD approach, but we aren't there yet.
I have some scenarios that involve business rules that I am trying to test with NUnitForms. For instance, if a record has a specific field populated, control x is disabled. Or, if you try to edit a record that is past status z then you get a message that says "xyz".
So, the way we edit a record in this application is by double clicking the row of the record in the data grid that you want to edit. Then a modal form opens with all the fields for that record and those fields need to be tested.
This is the scenario I have to test. Surely, this is a common issue.
Hi,
Yes, this sounds like classic UATs. Yes, I think this is a common issue as our team hit this too. Thing is the datagrid holds objects, how they are displayed is another matter. No brainer if the object is a string or Int etc but if it is a custom class or if you add a formatter then the datagrid is not determining what is displayed. e.g. Icon, colour, or just plain old text.
So, for a datagrid we had to get dirty and actually get the object from the grid control. This means you actually have to know about the object. Yea, real nasty. Maybe somebody has a great solution but to my knowledge the DataGrid formats dynamically and does not hold a record of what is displayed for each cell :-(.
Rob Smyth
My thinking is that NUnitForms is a framework for UATs and that is its future. A good future as there is a big need. I cannot see how NUnitForms can be used for "unit testing" as it inherently deals with .Net controls so the closest it could get is to do "integration tests".
The team I'm on does separate all controls to a thin 'view' which is basically just the designer generated form. We put an interface on this an mock it for all unit tests. When we need to pass a class like 'Control' into our code we wrap it into another class (Resharper can do this automatically for you) so we can get an interface ... and yep then mock it. The rule is that the only concrete class instantiated in a unit test is the class under test.
We use NUnitForms as the framework of a domain specific language for our application UATs. We use NUnit and NMock2 for our unit tests.
I recon NUnitForms has a great future pushed as a UAT rather than unit test framework.
See ya
Rob Smyth