HW IP verification has a lot of interesting tools and methodologies such as for instance constrained random testing. Another interesting aspect of this is that it enables metric driven verification since not only line and branch code coverage are measured but also functional and cross functional coverage.
Another interesting aspect of this is that there are tools that inserts errors to measure the quality of testing.
I wonder what is your view of the future of SW testing?
The post is great and it's covering an issue that most of us face; testing user interfaces.
The main problems / issues in any approach I have seen that is not in depth explained is how you wire together the various MVP triads in a project, how to communicate between them and how to set them up (especially in C++ that doesn't support garbage collection)
karlin I am a follower of the Presenter First pattern but I would like to see some more elaborate explanation on how it is different from the MVP pattern presented in this TotT. Some of the issues above are explained in the papers published by Atomic Object (like communication between presenters) but there the majority of issues I described above are still a bit unclear to me.
This is a great TotT, and I used this about 4 months ago while writing testable GWT (Google Web Toolkit) code. I and many others would enjoy a post particularly on GWT testability best practices.
The way MVP applied to my GWT example is I only let the views know about GWT widgets. The M and V wouldn't ever know about the widgets. They just responded to events and dealt with interfaces to the widgets. Then presenters and models can be junit tested (very very fast), and only the view needs the slower GWTTestCase.
Hi
ReplyDeleteI enjoy the blog!
HW IP verification has a lot of interesting tools and methodologies such as for instance constrained random testing. Another interesting aspect of this is that it enables metric driven verification since not only line and branch code coverage are measured but also functional and cross functional coverage.
Another interesting aspect of this is that there are tools that inserts errors to measure the quality of testing.
I wonder what is your view of the future of SW testing?
Great post!
ReplyDeleteOnce you get your feet wet with MVP, be sure to check out the Presenter First pattern for an intentional, testable approach to Model-View-Presenter:
http://www.atomicobject.com/pages/Presenter+First
The post is great and it's covering an issue that most of us face; testing user interfaces.
ReplyDeleteThe main problems / issues in any approach I have seen that is not in depth explained is how you wire together the various MVP triads in a project, how to communicate between them and how to set them up (especially in C++ that doesn't support garbage collection)
karlin I am a follower of the Presenter First pattern but I would like to see some more elaborate explanation on how it is different from the MVP pattern presented in this TotT. Some of the issues above are explained in the papers published by Atomic Object (like communication between presenters) but there the majority of issues I described above are still a bit unclear to me.
This is a great TotT, and I used this about 4 months ago while writing testable GWT (Google Web Toolkit) code. I and many others would enjoy a post particularly on GWT testability best practices.
ReplyDeleteThe way MVP applied to my GWT example is I only let the views know about GWT widgets. The M and V wouldn't ever know about the widgets. They just responded to events and dealt with interfaces to the widgets. Then presenters and models can be junit tested (very very fast), and only the view needs the slower GWTTestCase.