I am trying to bring the magic of Cocoapods to my company, but it has hit a tiny snag. We need to be able to unit test code that comes from Cocoapods.
So, my question is, has anyone else encountered this in their company (or is anyone just paranoid enough to care about unit testing this code and figured out how?). It may not be a deal breaker for us, but it will definitely help smooth things over with management if I have this sorted ahead of time.
We could probably insert the tests in the client app, but thats an awful lot of manual work considering we would use pods to reduce manual work. It would be nice to do it once somehow.
In my Podfile I use something like this: link_with ['Sail', 'Sail-Tests']
This links all my Pods with both my normal target and my test target. Then from my tests I can import and test whatever I want. This may overlap with 'inserting the tests in the client app' though.
If you would like to use a setup similar to the one created by Xcode (where the testing target depends on the one under test), another alternative is:
pod 'ObjectiveSugar', '~> 0.5'
target :test, :exclusive => true do
pod 'OCMock', '~> 2.0.1'
end
Marking a target exclusive indicates that it shouldn't inherit the dependencies of the parent. This prevents the duplicate symbol error with this setup.
I use Cocoapods to centralize the core functionality of a whole suite of over 20 apps, that are whitelabeled version of the same 'base' app. For this, I've setup a structure of two Xcode projects.
The first contains the core functionality including the unit tests verifying the expected behavior (Kiwi in my case). The specs as well as the xcodeproj don't show up in the podspec, but the project is tested under CI (Jenkins).
The second project contains the whitelabeled app (one project per app), and it has the dependency to the first project setup via the Podfile. In this light weight app are also Kiwi specs, that only test any custom code for that specific app. It does not test the core classes anymore, because they are already covered. This project is also under CI.
So the main answer-to-your-question part is that your library does not merely contain the source files necessary for the depending project, but also a compiling Xcode project (app or library) that runs the unit tests.
Related
I had a question regarding the Test APK topic.
Is there a way to use the tests/RunApkTests.targets and
build-tools/scripts/TestApks.targets
files. so I can reuse the targets to run my own android unit tests and get results as part as our continuous integration?
I tried using the NUnit Tutorial with no success. I also created an issue here but I kept researching and found some potentially useful targets there.
I'd rather use these targets through a nuget package as opposed to manually downloading the target files and their associated files.
Any suggestions?
Thank you for your time!
I am curious to know why when I create a new Aurelia project, each project installs +600 node_modules. Understandably, the modules collectively don't take up a lot of space, but are all of these modules necessary? I was under the impression that Aurelia's aim was to help developers move away from depending on 3rd party libraries so it seems odd that each project comes with a massive dump of 3rd party libraries.
My guess is that you are starting your project from CLI - which comes preset with HTTP server, ES6/2015, SASS, live-reloading and more.
I created clean Aurelia project and looked at the package.json - there were 5 dependencies and 34 dev dependencies. Using all of above mentioned tools is somewhat standard in today's JS web development, and generating project from CLI reduces time needed for upfront setup. All of these features come with their own dependencies, and that's why node_modules/ folder grows rapidly.
The bottom line is - you could start new Aureila project with much fewer dependencies. On their home page you can find starter project with just three. But that also means that you won't have access to most of the tools used today.
Also, and correct me if I'm wrong, I haven't got the impression Aurelia ever aimed to move devs from third party libs and modules, just to be modern, fast, and unobtrusive.
All modern web frameworks have a host of tooling. The reasons in no particular order -
1. Transpiling ESNext or TypeScript - if you want to write in Future JavaScript but have it work in all browsers, you need this step. Both Babel and TypeScript tooling comes with extra stuff too. If you want to see coverage (everyone does) there's another tool.
2. Testing - Unit test and End to End testing require testing frameworks, test runners, and if you want to write like above (esnext or TypeScript) you also need transpiling.
3. Module Loading / Bundling - Require.js, JSPM/System.js, WebPack, etc... are used to allow your code to actually run in the browser. Without a module loader you could not break your code out in to separate files. Without a bundler you would be loading a lot of extra files in production.
4. Serving your application - If you want to run your app locally you need a way to serve it up and watch for changes.
5. Debugging - You want to debug? Now you need a way to debug the file that gets served to the browser back to the original source.
6. Linting - Lint your code base for style consistencies.
Each of these packages usually have their own dependencies, and they get pulled down as well.
This convention of small packages that have a single focus is arguably better than massive packages that do everything for you. This allows you to remove a package and replace it with the one that does the same thing but in a way you want it.
It's getting quite frustrating with Xcode 5 here. All I'm trying to achieve is embedding some custom Cocoa frameworks into my project and create two versions of the app, one for the Mac App Store and one for a custom Online Store (so that when building for the MAS there'll be a folder called Debug (MAS) so I can distinguish it from the other version).
I embedded three frameworks into the project (only god knows why only one project can have another one embedded at a time, to hell with this limitation) and added their products in the "Link binary with libraries" and "copy frameworks" build phase. The finished built products are at the default location in the Library.
Now here's the thing - every time I'm using custom build configuration files other than "Debug" and "Release", the frameworks are NOT copied to the custom build folders but instead just go into "Debug" and "Release" regardless of any build options of the main app. Also, the frameworks are always built using "Debug" and are no longer connected to the current build mode (test, archive, etc.). To cut a long story short, this is a huge mess with file paths and obviously a lot of bugs concerning custom frameworks and custom build configurations.
Now my question is - there has to be an official or working way of maintaining an Xcode project that is both distributed over the MAS and a custom online store (two versions) and has at least one custom framework embedded. How do all other developers have solved this problem, I feel like I'm doing something fundamentally wrong and if I do, sorry for putting the blame on Xcode but something's for sure: Xcode's path management with external components is a chaos and the cause for unlimited mailing list and forum posts...
The answer is to create separate targets for the MAS & non-MAS app. You can add additional targets to build the custom frameworks and make the different targets dependent on each other (as necessary). Once this is all setup (properly) then building any of the targets will build any dependent targets (with the same build flags). And AFAIK there's nothing preventing an Xcode project from including multiple sub-projects so I haven't a clue why you believe this to be the case.
As far as I see every time I make a change, for example the value of a configuration variable, I have to
Make a copy of the change in each project (webapp, Android, IPhone, etc.)
Build each project
Distribute each project (besides the webapp)
I have found PhoneGap build which seems to be a great solution for the mobile part. But it's still beta and it doesn't solve everything. I still have webapp's code, which is not exactly the same.
Do you know techniques, tools or tricks, which help to improve this process?
Thanks in advance.
We are currently developing a web/Android app using PhoneGap and Sencha Touch (iOS is coming soon). So far our approach is as follows:
We have one project per platform plus several additional toolkit projects.
One platform is "primary", web in our case. This is what developers mainly use to develop and test the app. We're using jsTestDriver for testing.
During the build, the app is packaged for web in the first step. We're producing several artifacts here (.war file, tests in a .jar file).
"Secondary" platform projects do not include the source code. It gets unpackaged and copied to the right places when projects are built. This also includes tests from the primary platform.
Platform projects contain some additional code - normally only testing code, app code itself is currently cross-platform (not sure if it will stay this way).
So we're doing it mainly through advanced build scripts. We're using Maven for web and Android. iOS is coming soon (into our work, I mean), so we'll be looking for some sensible build tool there too.
We're building our projects using Hudson continuous integration.
What I have to admit is that this whole environment (multi-project Maven builds, JSTD, multi-node Hudson) is a hell of a setup, took quite an effort to figure it out.
I recently did some research on making a cocos2d app for iPhone/iPad AND Mac. I have done the iPhone/iPad route but have never done it with a Mac target. It appears that some people have added it as a target but mentioned that it is finicky and others have suggested making a separate Cocos2d Mac project that uses the same files. Any wisdom to impart here?
I believe it is absolutely crucial to have both iOS and Mac targets in the same project. Otherwise you'll spend too much time keeping one platform in synch with the other, until eventually you either manage to create a good (but still time-consuming) workflow - or end up neglecting one of the two platforms.
Ideally the code base should make as little use as possible of compiler macros. You'll want to compile both iOS and Mac code even if it's not being used for one platform. So having some classes or methods that are #ifdef'ed to Mac, others to iOS, will more often than not lead to compile errors when you switch targets. That means wrapper classes, so that you can write the same code regardless of the platform, are essential.
Right now, Cocos2D doesn't offer you to create iOS & Mac targets in the same Xcode project. The way to get there isn't immediately obvious either, because each target requires its own build settings for: Base SDK, SDK Root, Deployment Target, Architectures and possibly Compiler version. It gets worse if you also want to use 3rd party libraries (Box2D, Chipmunk, etc) because in some cases you'll be forced to create iOS and Mac specific targets for those libraries as well - if only to ensure that the library is built with the same compiler as the project's target, otherwise you can run into the strangest build or runtime issues.
I've had issues getting these platform specific targets to work within a single Xcode project without Xcode complaining or otherwise misbehaving. I haven't tried it with Xcode 4.1 and 4.2. By that time I had created .xcconfig files to host the build settings. The .xcconfig files may or may not be necessary with the more recent Xcode versions but they definitely make managing multiple platform-specific targets easier.
Long story short, the best and easiest way to do cross-platform development with cocos2d-iphone is by using Kobold2D.
Most of the 15 template projects have an iOS and Mac target in each project, you just need to select the corresponding scheme, then hit build & run. The most commonly needed platform-specific code (processing user input) is wrapped in a platform-agnostic, simple to use wrapper class KKInput.
Disclaimer: I'm the developer of Kobold2D. There's a slim chance that I may be biased. You should try Kobold2D anyway. :)