So I'm trying out this new TDD thing (about time haha). Anyways I have two unit testing files currently one for application and one for logic. The application logic test was autogenerated by xcode and when I go to manage schemes I can see the (void)testExample but I can't see the other tests I have created in my logic file, nor are they being run. Attaching picture.
Well it would help to read the docs a bit more carefully: http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/UnitTesting/03-Writing_Test_Case_Methods/writing_tests.html#//apple_ref/doc/uid/TP40002143-CH4-SW1
You just have to prepend your methods with 'test'.
i.e.
-(void)testmynewcase {
}
Related
The app I am trying to test makes use of feature toggles to enable/disable certain parts of the app. However, the tests I've written are for all the features. When a user logs in, this will fetch the feature toggles from a REST service (using a class which uses the generated openapi) so the app knows what to show and what not to show.
Now I want to include those feature toggles in my tests, so that the corresponding tests are skipped and don't just fail if some parts aren't enabled. However, when I try to include the class that does the call, I get problems with dart:ui in the console, and the test no longer runs. When I (recursively) check the imports on those service classes, there are some imports to widgets.dart, so I guess that's the problem. I tried removing most of it, but since we're using Localized strings for error messages etc. it's getting to be a very cumbersome job to remove all of that from those files.
So before I continue doing that, I was wondering if there is any easy way to include a call to a REST service in an integration test?
I checked the Flutter drive documentation, and searched for some similar questions online but haven't really found anything similar.
I have a D2006 app in which the DPR file has had numerous edits (yes, I know - you shouldn't mess with the DPR file) to accommodate such things as a splash screen, preventing a second instance of the app being started, handling of command line options that need to be processed before any forms are created, etc.
One day, I noticed that the auto-create forms list in the project options is empty - but the DPR file still has the code in there to create some of the forms.
If I try to restore all the forms that should be auto-created from the dialog, it complains Error - Call to Application->CreateForm is missing or incorrect and doesn't do anything.
How can I restore this connection - apart from rebuilding the DPR from scratch?
is it safe to manually add the CreateForm calls?
are there any documented rules as to what you can do in the DPR file?
I have a suspicion that try..except and if..else clauses in the DPR upset Delphi. Will moving as many functions as possible to a separate unit and calling them be helpful?
I haven't really seen any documented rules as to what you can do in the DPR file, because I guess there are no strict rules.
The problem begins when you create a "Forms" application. (No problems with console or non-GUI applications I've noticed).
The IDE will automatically change the DPR any time you add a new Form or a DataModule to it, by assuming you want to auto-create them.
This can mess up your DPR, if it has a lot of code/compiler-directives/if-blocks/try-catch blocks etc...
So I'll tell you what my rules are, and in a short line:
Keep it as simple as you can.
My DPR contains only a call to some init code and auto creates the main form only:
MyAppInit; // in AppInit unit
Application.Initialize;
Application.CreateForm(TMainForm, MainForm);
Application.Run;
However in the uses section I add (or keep what the IDE added) all the forms my application uses (and also application related units) - this is useful when I want to view->forms or view-units.
In-fact when I add a new form to the application, the first thing I do is go the DPR and remove the line:
Application.CreateForm(TMyNewForm, MyNewForm);
NOTE (EDIT): The IDE can be configured to NOT auto create forms (No Application.CreateForm entry will be created in the DPR). In older version of Delphi this option is under: Tools/Environment Options/Preferences -> Auto create forms. In newer versions: Tools/Options/VCL Designer/Module creation options -> Auto create forms & data modules.
At run-time, I create all my forms dynamically when I need them, and destroy them when they no longer needed. DataModules/Splash (etc...) are created on the MainForm.OnCreate event.
This method has worked for me nicely for the past few years maintaining a large scale DB application. This will probably not cover all cases, but it worked fine for my needs.
P.S: "Is it safe to manually add the CreateForm calls" - Yes. But think twice if you really need them to be auto-create by the application.
IMHO You don't really need that AutoCreate forms from Delphi, but maybe in the casual test project.
And the dpr is just another source code file, where you're meant to write code to make things happen (or prevent it to happen), so don't worry if you lost that sincronization, which IMHO is buggy if can't read your pascal code to work properly.
If you still want to create some forms from the DPR, add the Application.CreateForm or TMyForm.Create calls manually to the file, AFAIK there's no rules against doing it that way.
Since Delphi owns the .DPR, I put my startup logic into a separate unit for each project.
That works really well, only very few entries need to be in the .DPR.
Since that unit controls the Application.CreateForm logic too, the IDE has an empty list for that: I'm fine with that.
The only things left in the .DPR are:
the big uses that indicates which modules are part of your project
a call to Main in the startup logic unit
I have created an ios application that can talk to the database and get the messages from the server and all i want to do now is to distribute this aplication as a templet and other application can import my current project and use it, Now i been went throw many tricks and tips such as making an Static framwork using xcode bundles and Aggregate target type and got it work with some script found hear: http://codefriend.blogspot.com.au/2011/09/creating-ios-framework-with-xcode4.html
what i want to know is whether its the correct approach for such a problem or should i been looking at something else. All i want to create is an framework for my team so that they can produce other application
without worrying about or writing same files and code again and again. And is it possible to bundle all the .xib and .html files too?
This is what we use to create framework:
https://github.com/kstenerud/iOS-Universal-Framework
I'm writing a unit test with GHUnit. I would like to check if a file is being generated in the Caches directory within the Library directory of another app. Is this feasible, or are apps prevented from accessing each others' Library directories? And if so, are there any possible workarounds for creating a unit test for this? Could I possibly store the generated file in a different directory, such as Documents, or would that not help?
On device it is not possible at all. In simulator you can theoretically do it if you know the random UUID that names the directory that the application is installed in.
But I would highly discourage you from even trying. Instead make the code you intend to test stand enough of it's own to be testable. A unit test that verifies if another application behaves is on it's own almost as useless as a unit test that verifies that you call an API with the correct arguments.
I don't understand the context that you're attempting to unit test, so maybe my answer is wrong, but what I get is that you want to access your other app because GHUnit builds as a separate app.
There should be no reason to do this - instead of beating the sandbox problem, let's go around the whole issue.
Why not run whatever cache-creating code you are trying to test in the first place from the test target app, and then check the Libary/Cache directory of your bundle?
That's all there should be to it.
Apps can only access their own folders within their sandbox. Is your unit testing app separate from your app that you want to verify the cache contents of?
No, what you would need to do is use url prefixes and have the methods to do whatever you need done registered by that application on install.
I was googling a lot in order to find a solution for my problems with UI Automation. I found a post that nice summarizes the issues:
There's no way to run tests from the command line.(...)
There's no way to set up or reset state. (...)
Part of the previous problem is that UI Automation has no concept of discrete tests. (...)
There's no way to programmatically retrieve the results of the test run. (...)
source: https://content.pivotal.io/blog/iphone-ui-automation-tests-a-decent-start
Problem no. 3 can be solved with jasmine (https://github.com/pivotal/jasmine-iphone)
How about other problems? Have there been any improvements introduced since that post (July 20, 2010)?
And one more problem: is it true that the only existing method for selecting a particular UI element is adding an accessibility label in the application source code?
While UI Automation has improved since that post was made, the improvements that I've seen have all been related to reliability rather than new functionality.
He brings up good points about some of the issues with using UI Automation for more serious testing. If you read the comments later on, there's a significant amount of discussion about ways to address these issues.
The topic of running tests from the command line is discussed in this question, where a potential solution is hinted at in the Apple Developer Forums. I've not tried this myself.
You can export the results of a test after it is run, which you could parse offline.
Finally, in regards to your last question, you can address UI elements without assigning them an accessibility label. Many common UIKit controls are accessible by default, so you can already target them by name. Otherwise, you can pick out views from their location in the display hierarchy, like in the following example:
var tableView = mainWindow.tableViews()[0];
As always, if there's something missing from the UI Automation tool that is important to you, file an enhancement request so that it might find its way into the next version of the SDK.
Have you tried IMAT? https://code.intuit.com/sf/sfmain/do/viewProject/projects.ginsu . It uses the native javascript sdk that Apple provides and can be triggered via command line or Instruments.
In response to each of your questions:
There's no way to run tests from the command line.(...)
Apple now provides this. With IMAT, you can kick off tests via command line or via Instruments. Before Apple provided the command line interface, we were using AppleScript to bring up Instruments and then kick off the tests - nasty.
There's no way to set up or reset state. (...)
Check out this state diagram: https://code.intuit.com/sf/wiki/do/viewPage/projects.ginsu/wiki/RecoveringFromTestFailures
Part of the previous problem is that UI Automation has no concept of discrete tests. (...)
Agreed. Both IMAT and tuneup.js (https://github.com/alexvollmer/tuneup_js#readme) allow for this.
There's no way to programmatically retrieve the results of the test run. (...)
Reading the trailing plist file is not trivial. IMAT provides a jUnit like report after a test run by reading the plist file and this is picked up by my CI Tool (Teamcity, Jenkins, CruiseControl)
Check out http://lemonjar.com/blog/?p=69
It talks about how to run UIA from the command line
Try to check the element hierarchy, the table can be placed over a UIScrollView.
var tableV = mainWindowTarget.scrollViews()[0].tableViews()[0].scrollToElementWithName("Name of element inside the cell");
the above script will work even the element is in 12th cell(but the name should be exactly the same as mentioned inside the cell)