I am new to the concepts of UI Automation Testing so OCMock is decently foreign for me. I was having trouble approaching how I would mock a login. I'm also using the KIF framework which allows me to access things in a view with accessibility labels. However, I don't know how to access the accessibility labels of the view presented when Facebook opens a UIWebView so I'm attempting to mock a FBLoginView class and then mock a login to bypass this problem I'm facing.
Please help by either providing me with knowledge on getting through this with the KIF framework, or knowledge concerning how I would approach using OCMock to mock the FBLoginView class. Thank you
Sorry for making my question so vague but I have answered it myself. I believe the proper way to mock a Facebook login is to mock the FBLoginView Class. Then Mock the Protocol. Call the protocol method "loginViewShowingLoggedInUser:" and pass in the mocked class.
//mock class
id classMock = OCMClassMock([FBLoginView class]);
//mock delegate
id protocolMock = OCMProtocolMock(#protocol(FBLoginViewDelegate));
//mock delegate method
[protocolMock loginViewShowingLoggedInUser:classMock];
//verify delegate method called.
OCMVerify([protocolMock loginViewShowingLoggedInUser:classMock]);
Related
Edit: Thank you for the answers. They are helpful. My last question is, is it possible to do this via REST?
To start, I realize these have already been somewhat answered in the following two links, so please do not close this as a duplicate. I am legitimately confused!
MVC vs. 3-tier architecture?
MVC Vs n-tier architecture
From what I understand, the MVC design is for the "presentation" tier in the 3-tier architecture to allow for GUI creation. I get that. However, where I am confused is how the data model in the GUI is supposed to interact with the "Tier 2" application logic. This is how I am envisioning it:
So from what I gather, whenever a user interacts with the GUI, and the Model is updated, is it the model's responsibility to then talk to the rest of the architecture via a web server API?
Your controller contains the lightweight application logic, which is needed to coordinate work between model and view. For example, your controller has the responsibility to get the data from a service/data source, and map the resulting model into a view model that is given to your view.
Views should also contain as little logic as possible. As the view model is created specifically for a view, the only responsibility of the view is to render itself using the view model's data.
The model you are referring to is indeed the result of what you get back from the back-end. It could be proxy entities returned by a WCF service, data entities returned by a web API or entity framework objects if you access the database directly (all depends on what architecture you want to use). This model is then used to construct a view model, which your view uses to render itself.
Depends on how you wanna structure your project.
For example: Sometimes we don't want to expose our model classes (entities). So, we create DTO classes to receive information from UI, that will be handle by controllers and pass them to business logic that translate them to entities. It's used a lot in SOA solutions, where we can expose ours services.
Example: UI request -> Controllers with DTO -> BLL (translate to real model classes) -> Repository/DAO -> DB.
Discussion of tiers is really orthogonal to discussion of MVC.
MVC doesn't really talk about how the model is supposed to talk to outside services/data layers. There are some good discussions here about it. There is debate as to whether data access/persistence should be in your model layer, or your controller layer. I much prefer it in my model layer.
I also prefer the Anemic Domain Model, so I tend to put the actual talking to the DAO layer in the service part of the model, not the domain objects. But putting it into the model objects works well too, you just want to separate your persistence layer from your business logic layer with the DAO pattern.
The point is though, both your tiers need their own Model, and their own DAO layers. The DAO layer of the Presentation Tier will talk to the Business Tier. The DAO layer of the Business Tier will talk to your Database/Storage Tiers.
This isolates each tier from changes in the other tiers.
I need an axample to use CodeIgniter restful because this class can't work:
class Books extends REST_Controller
{
.....
}
I need to create a single point of access to both the login and for the register so that the register in a system the user has access to all the others, then I will have only one database to store and query data from users. My question is: What is the best option when it comes to Webservice, SOAP or REST? I read that SOAP is heavier and slower, however also read that REST has fewer features. What do you suggest me? Login via Webservice safe?
I have a controller with the Authorize attribute:
public CustomerController:Controller
{
[Authorize]
public ActionResult GetCustomer(int id)
{
var model=db.Customers.where(c=>c.id==id);
return View(model);
}
}
My question is, how can I test a controller with the Authorize attribute?
Do we need to get user information like username and password before testing from HttpContext?
Are mocks, dependency injection, and inversion of control related to unit testing? If so, can you guys suggest some websites or documents for learning these topics?
Here's some good examples of testing with mocks, DI, IoC, MVC #
http://code.google.com/p/sutekishop/source/browse/trunk/Suteki.Shop/Suteki.Shop.Tests/#Suteki.Shop.Tests%2FControllers
The author doesn't use the Authorize attribute but uses custom action filters and roles based security I believe.
I feel like exposing an edmx class as a parameter to a web service is not a good idea. I feel like it's wrong design. eg.
[WebMethod]
MyWebservice(int customerID, UserProfile profile){
}
now UserProfile is a class generated by Edmx framework. You might argue if the profile object is an input then it will not get a proper id (edmx id) because it will be created out of the context (since the web service can be called from any external consumer).
But i'm also looking for more explanation why exposing edmx class as a web service is not a good design. If you think it's ok, please tell me.
thanks
It's generally considered good design practice to keep the data contracts of a web service and the data model objects associated with a database separate, so that if required you could change the entity model used at the back of a web service, without having to change the interface that you expose to consumers of the service.
I have a two repositories Catalog and User, I have a situation where I need to call a method within the catalog repo from the user repo, is this good practice or is there a better way?
You shouldn't be handling those kind of authorization checks within your Repositories. A business rule like "This user requires X comments to post" isn't really a repository query, it's a property of your User.
Also, authorization calls are made very frequently in an application, and you really don't want to hit your database every time a check is required.
You should properly load these permissions into your User object which is then cached for the current request, and use your domain:
public class Service {
public void Save(Post post)
{
if(User.GetCurrentUser().HasEnoughCommentsToPost())
postRepository.Add(post);
}
}
I would reference the other Repository at the upper layer, such as a service layer
I think that in your case authorization is part of your domain logic. So I'd create an abstract class or interface called AuthorizationPolicy (maybe you can find a better name closer to your domain), in my domain layer. Before you call a method on the repository, the client should check if the have have permission based on the policy.
Another solution, because the interface of a repository is also part of the business logic, you can create a base class for your repository which check permissions of the user and delegate the rest to derived classes.
The implementation of the AuthorizationPolicy will talk to the Catalog class if you want. This way the two repositories are well decoupled.