I am learning MVC design pattern as an android developer and I've been seeing that it facilitates the testability of code. I understood this concept, but in real case I'm frustrated.
Can someone please explain how this is achieved in a real example?
3
-
4What do you think is the advantage of the MVX patterns? (MVC, MVP, MVVM, etc..). If you think it's the separation of concerns, then you answered yourself. Split and conquer. What do you think is easier to test, a big ball of mud where or code where each concern is encapsulated in well-defined components?– LaivNov 7, 2019 at 7:11
-
Could you tell us what is the cause of your frustration in your real example, so that we can understand what we should specifically address in our answers ?– ChristopheNov 7, 2019 at 7:29
-
@Christophe I just can't see the importance of this design pattern as everyone is just talking "scalability, maintenability, testability, ..." no real examples on testing with mvc.– AmineNov 7, 2019 at 15:04
Add a comment
|
1 Answer
MVC stands for model view and controller. One can view MVC as an extension of Single Responsibility principle. The reason for a change in each of these components would be different.
The Model: models the business. The details of http and rest are not supposed to be in this component. Ideally if you decide to make your application as desktop application then you should be able to reuse the model component.
The View: has the details of the view. They are mostly about input/output. This component can depend on the model component. After all you are showing the data from the model here.
The Controller: Binds the model and views together by taking of the HTTP concerns such as return code.
I am learning MVC design pattern as an android developer and I've been seeing that it facilitates the testability of code.
Now coming to your question of how this improves testability. There are different types of testing. Understanding the capabilities and limitations of different types of testing methods are important in answering this question. There are many types of testing, and we could look at unit testing, integration testing and system testing.
Unit Testing: Ideally unit tests have to run quickly and give the results quickly. The details of HTTP call or database call would be often mocked out. This would be very suitable to test business logic. These are often fully automated and integrated with the build.
Integration Testing: Integration tests integrate different aspects of the business and tests. They could integrate infrastructure aspects as well for testing. They are bit more time consuming to execute that unit test. They can often be fully automated.
System Testing: This is testing the system fully. They are often time consuming. They could be automated using tools like selenium. They are many a times manually don.e
How testing is made easier: When we separate the code in to these 3 components (model, views and controllers). The model would now contain all the business logic. A huge percentage of your code base would be in the model component. By mocking out the infrastructure code (such as talking to DB or making other HTTP calls, etc...), this component can be fully unit tested.
The presence of UI would make unit testing quite difficult if not impossible. Also testing of the web server aspects of the application by unit testing is also a bit difficult. Now having separated that code in to view and controllers will make the model easy to unit test would be another way of looking.
This was we are able to test most of the code with highly quick unit testing, and test the other aspects with fewer integration and system tests.
Summary:
- In MVC, model depends on nothing, view depends on model, and controller depends on view & model.
- If A is dependent on B, and B is not unit testable, then A is not unit testable.
- View and Controller are not unit testable (or at least difficult to unit test).
- In MVC, most of the code will be in the model.
- By Making model NOT dependent on view and controller, model (most of the code) becomes unit testable.
answered Nov 7, 2019 at 6:17
-
Interesting thoughts! Are you sure that "layer" is the right term here ? I understood that layered architecture generally would imply that one layer speaks only with the layer immediately above and immediately under it, whereas MVC was more like a triangle. And what about Views managing input ? Isn't input a responsibility of C in the original MVC (whereas it would indeed be V but in MVVM or MVP) ? Nov 7, 2019 at 7:24
-
Layers I think the term is loosely used here. After you comment, when I googled, I realized some articles have used the term layer for it and some have carefully refrained from using the term layer. If a layer is supposed to talk only to one layer below and above it, then off course, this would not be a layers. If on the other hand if a layer is allowed to talk any number of layers below it but nothing above it, then this would be layers. However thanks for your comment, I would prefer to use another term instead of layer. Let me respond to the last part of your comment in another comment Nov 7, 2019 at 8:09
-
@Christophe, now if this is viewed as components, then I hope all your concerns would be taken care off... isn't it? From the triangulation, just want to confirm that you don't mean "view depends of controller". Nov 7, 2019 at 8:20
-
I understand. MVP and MVVM are layered and a lot of articles out there make the confusion. May I suggest “component” ? This would reflect the relative independence of these elements. Nov 7, 2019 at 8:25
-
2In MVC, model depends on nothing, view depends on model, and controller depends on view & model. If A is dependent on B, and B is not unit testable, then A is not unit testable. View and Controller are not testable. By Making model not dependent on view and controller, model becomes testable. In MVC, most of the code will be in the model Nov 7, 2019 at 15:58