Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I would like to implement UI Testing for my app, but I couldn't find anywhere some guides on how to structure the tests, group them or which is the best way to proceed writing the tests - a big flow in a test, or multiple tests for smaller flows.
If you have some resources regarding these topics, any help would be appreciated.
Thank you!
You can use this as reference https://www.raywenderlich.com/960290-ios-unit-testing-and-ui-testing-tutorial
and this one https://www.hackingwithswift.com/articles/148/xcode-ui-testing-cheat-sheet
For UI Testing, you must record first your test cases, and Xcode will fill automatically the codes for you(But I don't do this approach since I preferred to do it manually and programmatically, so I don't have to record all the event's that I need to test)
I assign a accessibilityIdentifier to every views/buttons and etc, that I have so I can call/compare it inside the UITest Class.
I grouped them depending on the scene that I want to test like for example I created test cases that would start from login. And separate test cases that would start from registration, depending on the state of your app.
In addition to this, I have created a simplified pattern and created an Example project to implement UI Testing from this repository https://github.com/michaelhenry/AutoBot
Update:
For testing views that are created using SwiftUi,
You can use the method “.accessibility(identifier: “your_control_accessibility_identifier”)”
I believe there is no general answer to your question, since UI testing depends essentially on the UI of your app.
In the app I am currently working on, I test scene by scene, i.e. the controls of every view controller. So, some of them are related to basic functions, some to iCloud setup, etc.. I believe - but I don’t have too much experience - that testing scene by scene is straightforward, if your scene structure is clear, and it is relatively easy not to omit essential functions.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to create an app with ability for user to log in via Facebook, Twitter, Google, and LinkedIn. I'm using a single UIViewController and adding more and more code to viewDidLoad method. At this point my controller looks awful and I would like to split the code between associated classes (one for Facebook, and so on). I even thought about using custom views for every social media login button...
What would be the right thing to do?
There are at least two things to split in your case.
Login with different networks. It purely depends on your UI. You might have a separate view (and corresponding class) for each network or a popup.
Split code by applying an architectural pattern (MVC, MVVM, VIPER, etc.)
Here is a nice overview of them:
https://techblog.badoo.com/blog/2016/03/21/ios-architecture-patterns/
Additional change you should do is to introduce a separate bunch of classes to handle log in via social networks. Then in your view controller (or better in a View Model or somewhere else, depending on the design pattern you choose) you call SocialNetworkService.authenticateWithTwitter(email:password)
But remember, these classes have to know nothing about view controller.
I hope my answer gives you a hint in which direction to go.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I joined a startup where my boss, so called Technology Head with 3 years experience has written the code and the website is running, She doesnt know testing and things are breaking apart now.
I have been Following TDD in my life, now I dont know how to test the RAILS APPLICATION where 50k LOC has already been written, waste code has piled up and there is no proper flow of the code at all.
How can I unit test the existing modules?
How can I refactor the maximum code with Test After Development approach for the existing code?
I am going bonkers with the existing code.
Cant make it again, not sufficient freedom to make it again.
Thanks in advcance
You could write a book on this subject (in fact I belive Mike Gunderloy did - Rails Rescue Handbook - though I can't seem to find a place to get it online now).
The short story is:
Unfortunately, it doesn't make business sense to retrospectively write tests for everything in the existing code base if it's basically working, so don't do that.
Start always writing tests for new features, and insisting others do too.
Whenever something in the existing codebase breaks, be sure to write a regression test.
When you make significant changes in the existing codebase, if it makes sense, add tests at the same time. Don't bother adding tests for small changes that can be easily manually verified; it likely isn't worth the time.
You probably already knew all that though. Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The title says it all, if I test using capybara :
visit this page
expect this content
and do this for every single feature(e.g signin, signup, search, clicking all the links and buttons, etc), would that be enough? Why would I need to test controllers and models? If features are working as expected, doesn't that mean everything is working in harmony?
That technique is called black box testing also know as functional testing. If you are testing as if you are a user of the application it is considered black box. If you are testing it from within it is considered glass box testing.
The question of whether or not is it enough is a matter of personal opinion. My opinion is if it is thorough enough then yes it could be enough.
Some of the advantages of black-box testing include:
You have a good chance of writing tests that weren’t imagined by the programmer.
The environment the program is running is also tested
The invested effort can be used multiple times
Some advantages of glass-box testing include:
It forces you to reason carefully about implementation.
Spots the Dead Code or other issues with respect to best programming practices.
Reveals errors in hidden code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm about to start building a Rails app that will eventually need to vary CRUD access by user (i.e. which pages do they see, which can they edit, etc).
Is there a best stage of the development cycle to incorporate this?
Part of me feels like it should be the very first thing, since almost every piece of the interface will in some way rely on checking the user's ID, and it will be an inherent part of the DB structure.
Another part feels that this would overcomplicate things to start out with, and that I should instead build the core parts of the app, then layer on the authentication/authorization later.
Are there any best practices around this sort of thing?
I would say that if your system will rely on some kind of authentication... Why wait?
Let's say that you start developing your application without the authentication layer but at the same time you know that at some point you will have to do it. That means that at some point you will develop the authentication layer, and most likely you will have to refactor what you have already built to adapt it to this new layer.
Also, to try to convince you a little bit more...When you say:
I should instead build the core parts of the app
You should consider that the authentication module might be a core part of the app too...
I prefer to do it early, but you really have roughly the same amount of work in front of you regardless of when you do it. It really a matter of opinion on when you prefer to do it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
This app had virtually no tests in place when we came to it and now there are cucumber tests covering the most essential parts. We are not sure if the app is working correctly and have had many disasters happen over the course of development, most of them caused by bugs that were never discovered. The code is quite ugly in places with models generating HTML and PHP-itis in the views. There are many extraneous models and controllers that could be greatly simplified or eliminated. My question is, when is it better to simply refactor code without testing previous functionality? Due to deadline constraints, it's very hard to justify spending time on covering all the existing code with tests when we know it's bad and could be easily eliminated.
I'm gonna guess this is a client project. My approach would be to write Cucumber tests to cover the behavior of the project only, and then write RSpec implementation tests that cover the new code you'll be writing.
Get the client to sign off on the behavior tests, this way, when you start changing the implementation, you can be sure you haven't drastically modified the behavior of the app. Then, write the tests for the code you wish you had, and refactor until the tests are all green.