Wildcard resolving in paths + Unit testing #713

Merged
merged 7 commits into from Mar 8, 2012

Projects

None yet

3 participants

@HenningJ
Quicksilver OS X member

This fixes #633.
Before this, when it had to resolve a directory, it would just use the last file in that directory. Even if the rest of the path then wouldn't lead to a file. For example the path to resolve would be ~/Library/Application Support/Firefox/Profiles/*/places.sqlite and ~/Library/Application Support/Firefox/Profiles/ would contain one actual profiles folder (aaa.default) and some other file ('yyy.txt´), it would resolve to /Users/X/Library/Application Support/Firefox/Profiles/yyy.txt/places.sqlite, even though that file obviously doesn't exist.

Now it uses the first file instead, but only, if the final file actually exists.

But the more interesting part of this pull request is that I set up a unit testing environment for Quicksilver. I'm sure using unit testing would greatly benefit Quicksilver development. But I'll try to write more about that on the dev-list soon(ish). For now I have just set up tests for the QSFoundation.framework and added some tests for the changes in this pull request. Check out anything in the Tests group and the FoundationTests target. Just building that target should compile the QSFoundation.framework and run the corresponding tests.

@skurfer
Quicksilver OS X member

FYI, I am using and testing this but haven’t had time to try the unit test stuff. I’m excited about it though.

@skurfer
Quicksilver OS X member

Just building that target should compile the QSFoundation.framework and run the corresponding tests.

Finally trying this out. FYI, in Xcode 4, I had to use Test, not Build. Maybe that’s new. Anyway, really cool.

There are so many things we could/should be testing. I’ve always thought it would be impossible with all the dependencies everywhere, but we should at least try. :-)

Oh, and the path resolving changes look good, too.

@skurfer

Any reason not to use fast enumeration here?

Quicksilver OS X member

P.S. @HenningJ - could use fast enumeration here if you're updating this stuff :)

for (NSString *aString in contents) { ...
Quicksilver OS X member

Rob already suggested this, I changed it and it was included in the final change. But thanks for the suggestion. :-)

Quicksilver OS X member

Whoops, I should have look at the final pull request :P

@HenningJ
Quicksilver OS X member

Finally trying this out. FYI, in Xcode 4, I had to use Test, not Build. Maybe that’s new. Anyway, really cool.

I'm surprised that's the only thing you had to change. I thought there were quite a few changes related to unit testing. Cool :-)

There are so many things we could/should be testing. I’ve always thought it would be impossible with all the dependencies everywhere, but we should at least try. :-)

Yes, I would love to solve some of these dependencies. I have some ideas how to do it (I just read "Working Effectively with Legacy Code" which is all about resolving dependencies and creating tests), but many things can't be changed, because that would break a lot of the plugins. We have to be quite careful with that.

Any reason not to use fast enumeration here?

No, you right. I just...forgot. Will change that.

HenningJ added some commits Mar 3, 2012
@HenningJ HenningJ Using fast enumeration. c009c31
@HenningJ HenningJ Added the test architecture for the other frameworks (QSCore.framewor…
…k, QSEffects.framework, QSInterface.framework).
46bb4f8
@HenningJ HenningJ Added test architecture for Quicksilver application. To be used for e…
…verything that doesn't fit into the other test-targets. Also added a target to run all tests.
b59ad0c
@HenningJ
Quicksilver OS X member

Any reason not to use fast enumeration here?

Changed that in c009c31.

I also added the testing stuff for the other frameworks and for QS itself.
The test classes should go in the corresponding group in XCode and the correct folder on disk, to keep them separate from the actual applications files. For example for tests of the QSCore.framework should go in Tests/QSCoreTests group and in the folder Tests/Tests-QSCore/.
And of course they need to be added to the correct test target. And not any of the normal targets! :-)

For each test target there is a dummy test file. That needs to be there, because the target will fail if there are no test files. Once there are any real tests for a test target, the dummy test file can be removed.

I also added a target ("Run All Tests") to easily run all existing tests.

We could (or rather: should) also add tests for the plugins. But for now, I think this is a good setup to get started.

@skurfer
Quicksilver OS X member

I’m good with all of this, but I’d like the documentation to exist somewhere other than some comments on GitHub. :-) Can you summarize it on the wiki or add a Markdown file to the repo as part of this pull request?

@HenningJ
Quicksilver OS X member

You're right. I added a wiki page: http://qsapp.com/wiki/UnitTests
Please check it and maybe add something about XCode 4 (if it isn't clear). Or let me know if I forgot something.

@skurfer
Quicksilver OS X member

I added a wiki page

Thanks.

Please check it and maybe add something about XCode 4 (if it isn't clear).

Looks good, but Run All Tests doesn’t seem to do anything, so I need to look into that.

@skurfer skurfer merged commit d826a2c into quicksilver:master Mar 8, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment