Integration Test, GUI and Presenter

　　Recently, I had some discussion about how to do integration testing with my co-works. For example, we need verify one row in the table view in the GUI, we want do integration test for it. Firstly we need load some data, trigger some calculation, create some data and then display them in the table view in GUI. He thinks it’s impossible to do the integration testing for it. But I said, yes, you are right, currently we have no way to do integration test for this in our current system, but that doesn’t mean we cannot do integration testing.  Why we cannot do it, because our system design is bad. Currently, our design always lives with GUI, but do we need GUI to create software? Absolutely NOT! If we construct software at the beginning without GUI in our mind, It will be easier for us do the integration testing.

      Now days, almost every software is GUI application, that’s why it’s too easy for us design system associated with GUI. That’s wrong, total wrong. We should design system without GUI in our mind. GUI is the last thing we should concern. We should take more efforts in domain model design.

      MVP pattern seems like more and more popular, but unfortunately, MVP has been retired for many years; Both Passive View and Supper Controller patterns are more applicable in our modern software development. Personally, I like Passive View more because it can make UI be thiner. That means we can do more tests for the presenter. We can take less efforts and money on GUI automation testing.

      We always have presenter class no matter using Passive View, Supper Controller or MVP. Most of time, we also find our presenter class is too big, we want to spit it, but we don’t know what should be extracted and where they should be put. Why? Because we still don’t know what the presenter is, I mean what responsibilities presenter should take.

　　Presenter only exists if UI exists. That’s the right position of presenter in our system architecture. Presenter should not hold domain logic, just reminder, on the above, I have said, we should construct our software without GUI in our mind. All domain logic should be hold in our domain layer and application layer.

　　Now, we have known presenter should not hold domain logic, then what logics presenter should take. Imagine you have Windows application as the GUI, one day, you must support Web Application as the GUI, but you should use the same presenter, when you implement this, you will easily know what logics presenter should take.

　　Presenter holds UI logic without concrete UI in our mind.

　　We should move our focus from UI layer, take more efforts on our domain layer design, Then we can easily do integration testing. Presenter exists for UI, should only hold UI logic not domain logic.