Code Monkey home page Code Monkey logo

specta's Introduction

Specta

A light-weight TDD / BDD framework for Objective-C.

FEATURES

  • An Objective-C RSpec-like BDD DSL
  • Quick and easy set up
  • Built on top of XCTest
  • Excellent Xcode integration

SCREENSHOT

EXAMPLE

#import <Specta/Specta.h> // #import "Specta.h" if you're using libSpecta.a

SharedExamplesBegin(MySharedExamples)
// Global shared examples are shared across all spec files.

sharedExamplesFor(@"foo", ^(NSDictionary *data) {
    __block id bar = nil;
    beforeEach(^{
        bar = data[@"bar"];
    });
    it(@"should not be nil", ^{
        XCTAssertNotNil(bar);
    });
});

SharedExamplesEnd

SpecBegin(Thing)

describe(@"Thing", ^{
  sharedExamplesFor(@"another shared behavior", ^(NSDictionary *data) {
    // Locally defined shared examples can override global shared examples within its scope.
  });

  beforeAll(^{
    // This is run once and only once before all of the examples
    // in this group and before any beforeEach blocks.
  });

  beforeEach(^{
    // This is run before each example.
  });

  it(@"should do stuff", ^{
    // This is an example block. Place your assertions here.
  });

  it(@"should do some stuff asynchronously", ^{
    waitUntil(^(DoneCallback done) {
      // Async example blocks need to invoke done() callback.
      done();
    });
  });

  itShouldBehaveLike(@"a shared behavior", @{@"key" : @"obj"});

  itShouldBehaveLike(@"another shared behavior", ^{
    // Use a block that returns a dictionary if you need the context to be evaluated lazily,
    // e.g. to use an object prepared in a beforeEach block.
    return @{@"key" : @"obj"};
  });

  describe(@"Nested examples", ^{
    it(@"should do even more stuff", ^{
      // ...
    });
  });

  pending(@"pending example");

  pending(@"another pending example", ^{
    // ...
  });

  afterEach(^{
    // This is run after each example.
  });

  afterAll(^{
    // This is run once and only once after all of the examples
    // in this group and after any afterEach blocks.
  });
});

SpecEnd
  • beforeEach and afterEach are also aliased as before and after respectively.
  • describe is also aliased as context.
  • it is also aliased as example and specify.
  • itShouldBehaveLike is also aliased as itBehavesLike.
  • Use pending or prepend x to describe, context, example, it, and specify to mark examples or groups as pending.
  • Use ^(DoneCallback done) as shown in the example above to make examples wait for completion. done() callback needs to be invoked to let Specta know that your test is complete. The default timeout is 10.0 seconds but this can be changed by calling the function setAsyncSpecTimeout(NSTimeInterval timeout).
  • (before|after)(Each/All) also accept ^(DoneCallback done)s.
  • Do #define SPT_CEDAR_SYNTAX before importing Specta if you prefer to write SPEC_BEGIN and SPEC_END instead of SpecBegin and SpecEnd.
  • Prepend f to your describe, context, example, it, and specify to set focus on examples or groups. When specs are focused, all unfocused specs are skipped.
  • To use original XCTest reporter, set an environment variable named SPECTA_REPORTER_CLASS to SPTXCTestReporter in your test scheme.
  • Set an environment variable SPECTA_SHUFFLE with value 1 to enable test shuffling.
  • Set an environment variable SPECTA_SEED to specify the random seed for test shuffling.

Standard XCTest matchers such as XCTAssertEqualObjects and XCTAssertNil work, but you probably want to add a nicer matcher framework - Expecta to your setup. Or if you really prefer, OCHamcrest works fine too. Also, add a mocking framework: OCMock.

STATUS

Specta is considered a done project, there are no plans for active development on the project at the moment aside from ensuring future Xcode compatability. Therefore it is a stable dependency, but will not be moving into the Swift world. If you are looking for that, we recommend you consider Quick.

RUNNING SPECTA'S TESTS IN COMMAND LINE

  • Run rake test in the cloned folder.

CONTRIBUTION GUIDELINES

  • Please use only spaces and indent 2 spaces at a time.
  • Please prefix instance variable names with a single underscore (_).
  • Please prefix custom classes and functions defined in the global scope with SPT.

Installation

Use CocoaPods, Carthage or Set up manually

CocoaPods

  1. Add Specta to your project's Podfile:
target :MyApp do
# your app dependencies

  target :MyAppTests do
    inherit! :search_paths

    pod 'Specta', '~> 2.0'
    # pod 'Expecta',     '~> 1.0'   # expecta matchers
    # pod 'OCMock',      '~> 2.2'   # OCMock
    # pod 'OCHamcrest',  '~> 3.0'   # hamcrest matchers
    # pod 'OCMockito',   '~> 1.0'   # OCMock
    # pod 'LRMocky',     '~> 0.9'   # LRMocky
  end
end
  1. Run pod install in your project directory.

Carthage

  1. Add Specta to your project's Cartfile.private

    github "specta/specta" ~> 2.0
    
  2. Run carthage update in your project directory

  3. Drag the appropriate Specta.framework for your platform (located in Carthage/Build/) into your application’s Xcode project, and add it to your test target(s).

  4. If you are building for iOS, a new Run Script Phase must be added to copy the framework. The instructions can be found on Carthage's getting started instructions

SETTING UP MANUALLY

  1. Clone from GitHub.
  2. Run rake in project root to build.
  3. Add a "Cocoa/Cocoa Touch Unit Testing Bundle" target if you don't already have one.
  4. Copy and add all header files in Products folder to the Test target in your Xcode project.
  5. For OS X projects, copy and add Specta.framework in Products/osx folder to the test target in your Xcode project. For iOS projects, copy and add Specta.framework in Products/ios folder to the test target in your Xcode project. You can alternatively use libSpecta.a, if you prefer to add it as a static library for your project. (iOS 7 and below require this)
  6. Add -ObjC and -all_load to the "Other Linker Flags" build setting for the test target in your Xcode project.
  7. If you encounter linking issues with _llvm_* symbols, ensure your target's "Generate Test Coverage Files" and "Instrument Program Flow" build settings are set to Yes.

LICENSE

Copyright (c) 2012-2022 Specta Team. This software is licensed under the MIT License.

specta's People

Contributors

antondomashnev avatar brow avatar danpalmer avatar dasmer avatar dbarden avatar eunikolsky avatar gfontenot avatar jmoody avatar joshaber avatar jspahrsummers avatar matejbalantic avatar mdiep avatar mickeyreiss avatar modocache avatar nerdyc avatar orta avatar owjsub avatar paweldudek avatar petejkim avatar readmecritic avatar rhgills avatar robb avatar sbl avatar shockdesign avatar skunkworks avatar timbodeit avatar tommeier avatar tonyarnold avatar wasnotrice avatar yujinakayama avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

specta's Issues

Specta + lcov Code Coverage Addition

Hi ,
i was trying to get code coverage on my ios project using specta , i had already managed to do that using xctest following this solution (http://stackoverflow.com/questions/19136767/generate-gcda-files-with-xcode5-ios7-simulator-and-xctest )

After struggle a little bit i've realized that if i override the XCTestLog_stopObserving method of XCTestLog+Specta.m , and add these 2 extra lines(Bold).

  • (void)XCTestLog_stopObserving {
    if ([self spt_shouldProxyToSPTReporter]) {
    [[SPTReporter sharedReporter] stopObserving];

    UIApplication* application = [UIApplication sharedApplication];
    [application.delegate applicationWillTerminate:application];
    

    } else {
    [self XCTestLog_stopObserving];
    usleep(100000);
    }
    }
    and inside my AppDelegate's willTerminate method , i've added this lines(From stackoverflow solution) :

  • (void)applicationWillTerminate:(UIApplication *)application
    {

    ifdef DEBUG

    extern void __gcov_flush(void);
    __gcov_flush();

    endif

    }
    With this steps done , i could manage to generate the .gcda that lcov/gcovr need to create the code coverage.

This solution does not require to create a GcovTestObserver as the stackoverflow thread suggest nor to override the load method on appDelegate if in debug mode .

Can i use this approach ? Does it make sense to have this extra lines inside this method ?

I've created a shell script to override this method inside the pods dir adding this 2 lines , so i could use it as pre build step with my ci server after a pod install .
Right now , im using it as a workaround solution . Can i hope to see this workaround done inside specta , or another solution to answer the problem of .gcda files not being generated.

Thanks for your time , Best regards

test method names are not correctly generated...

describe(@"foo", ^{
   describe(@"bar", ^{
      it(@"red", ^{});
      it(@"green", ^{});
   });

   describe(@"baz", ^{
      it(@"blue", ^{});
      it(@"yellow", ^{});
   });
});

expected:

foo_bar_red
foo_bar_green
foo_baz_blue
foo_baz_yello

actual:

foo_bar_red
foo_bar_red_green
foo_bar_baz_blue
foo_bar_baz_blue_yellow

pending specs

it(@"is pending", nil);

xit(@"is pending");
xit(@"is pending", ^{});

pending(@"some pending task");
pending(@"some pending task", ^{}); // this can be done.

xdescribe, xcontext, xspecify, xexample etc

When an exception is raised in an example, after hooks do not run

If an example raises an exception, after hooks do not seem to be run. This can leave a polluted test environment when later tests run.

I've verified this in my own project with global afterEach: methods, but from a reading of the code I believe all after hooks will be skipped.

crash before any tests run on v 0.1.9

If I have any tests in an application target defined with Specta I crash before any run. If i switch my pod dependency to v 0.1.8 there is no crash. I've tested this on a bare ios application (no code except the starting code from the xcode template) in xcode 4.6.3 running on simulator 6.1. Writing tests on a static library project has no problems, this is only happening if the project is an application. Below is a screenshot of the crash.

screen shot 2013-07-03 at 11 33 19 pm

Shared behavior doesn't fail when missing

I took the example from the Github project page, but removed the whole SharedExamplesBegin -> SharedExamplesEnd section:

#import "Specta.h"

SpecBegin(Thing)

describe(@"Thing", ^{
  sharedExamplesFor(@"another shared behavior", ^(NSDictionary *data) {
    // Locally defined shared examples can override global shared examples within its scope.
  });

  beforeAll(^{
    // This is run once and only once before all of the examples
    // in this group and before any beforeEach blocks.
  });

  beforeEach(^{
    // This is run before each example.
  });

  it(@"should do stuff", ^{
    // This is an example block. Place your assertions here.
  });

  it(@"should do some stuff asynchronously", ^AsyncBlock {
    // Async example blocks need to invoke done() callback.
    done();
  });

  itShouldBehaveLike(@"a shared behavior", @{@"key" : @"obj"});

  itShouldBehaveLike(@"another shared behavior", ^{
    // Use a block that returns a dictionary if you need the context to be evaluated lazily,
    // e.g. to use an object prepared in a beforeEach block.
    return @{@"key" : @"obj"};
  });

  describe(@"Nested examples", ^{
    it(@"should do even more stuff", ^{
      // ...
    });
  });

  pending(@"pending example");

  pending(@"another pending example", ^{
    // ...
  });

  afterEach(^{
    // This is run after each example.
  });

  afterAll(^{
    // This is run once and only once after all of the examples
    // in this group and after any afterEach blocks.
  });
});

SpecEnd

However, the following line still remains:

  itShouldBehaveLike(@"a shared behavior", @{@"key" : @"obj"});

So I'd expect a failure. Alas, all of the tests pass! Including that one…

  -[ThingSpec Thing_a_shared_behavior]
    Test Case '-[ThingSpec Thing_a_shared_behavior]' started.
    Test Case '-[ThingSpec Thing_a_shared_behavior]' passed (0.000 seconds).
…
  Test Suite 'All tests' finished at 2014-03-31 22:45:22 +0000.
  Executed 6 tests, with 0 failures (0 unexpected) in 0.248 (0.250) seconds

6 tests; 0 skipped; 0 failures; 0 exceptions; 2 pending

Which I traced to the following code in Specta.m:

SPTXCTestCase *currentTestCase = SPTCurrentTestCase;
if (currentTestCase) {
  [currentTestCase recordFailureWithDescription:@"itShouldBehaveLike should not be invoked inside an example block!" inFile:@(fileName) atLine:lineNumber expected:NO];
} else {
  it(name, ^{
    [currentTestCase recordFailureWithDescription:[NSString stringWithFormat:@"Shared example group \"%@\" does not exist.", name] inFile:@(fileName) atLine:lineNumber expected:NO];
  });
}

This code does seem a bit absurd, saying if the object is nil call a method on it. Sure enough, when we get there it's nil in the debugger and the method does nothing.

XCTest integration

Xcode 5 projects default to using XCTest instead of OCUnit. Specta should support XCTest when Xcode 5 is released.

I tried to port Specta once, and the changes were pretty intrusive. Perhaps we should create a xcode5-only branch and try it out there?

itsShouldBehaveLike not executing as expected

I have a shared example which takes a service, the service is shared in the spec and loaded in a beforeEach. I expect if I use a block in the itShouldBehaveLike then the parameters passed to the shared example are evaluated lazily. However this never happens. I have stepped through the code and noticed that in Specta.m in the SPTitShouldBehaveLike method that: block(dataDict) is called before the beforeEach(^{ which loads the dataDict and therefore my parameters aren't passed through.

Is this the intended behaviour? If so how can I achieve what I want.

Shared behaviour and spec (forgive any syntax issues, I have tried to remove domain specific information, but my code complies and executes):

SharedExamplesBegin(Example)

sharedExamplesFor(@"Example", ^(NSDictionary *data) {
    __block id thing = data[@"thing"];    
    it(@"checks stuff", ^AsyncBlock{
        ....
        done();
    });
});

SharedExamplesEnd

And a spec:

SpecBegin(Spec)

describe(@"S[ec", ^{
    __block id *service;
    beforeEach(^{
        service = [[Service alloc] init];
    });

    __block Model *model = [[Model alloc] init];
    itShouldBehaveLike(@"Example", ^{
        return @{
                 @"thing": service
                 };
    });
SpecEnd

shared examples

sharedExamplesFor(@"foo", ^(NSDictionary *dict) {
  describe(@"bar", ^{
    it(@"does something.", ^{});
  });
});

describe(@"baz", ^{
  itShouldBehaveLike(@"foo");
});

describe(@"qux", ^{
  NSDictionary *dict = [NSDictionary ...];

  itShouldBehaveLike(@"foo", dict);
});

// sharedExamplesFor <=> sharedExamples
// itShouldBehaveLike <=> itBehavesLike

Provide a way to get the complete spec description at runtime

There should be a way to get the value in the current it(@"this is the string I want") block, the value that is visible in XCode as "this_is_the_string_I_want" as well as the complete string with parent context.

describe(@"A spline", ^{
  it(@"is reticulated", ^{
    // I want to be able to get:
    //  "is reticulated"
    //  "is_reticulated"
    //  "A spline is reticulated
    //  "A_spline_is_reticulated"
  });
});

failing shared example

When using some shared example, if one test if failing, the error is reported in the issue navigator, but there is no red marker on the code line where the itShouldBehaveLike is called.

Also clicking on the error in the issue navigator navigates on a wrong line in the editor

New reporter output format breaks Jenkins test report parsing

Hi,

We recently updated Specta from 0.1.8 to 0.1.11. Whilst the new reporter output format is certainly very nice when running locally, we found that it broke JUnit output report parsing on our Jenkins instance:

FATAL: Log statements out of sync: current test suite was null

It would certainly be nice to keep up to date with Specta. Perhaps the new reporting format could be disabled with an environmental variable? This would be more easily controlled when configuring the Jenkins job. Alternatively, the parser plugin may be updated, but since the old OCUnit format is so well established I don't see this happening particularly soon.

In any case, looking forward to hearing from you regarding this matter. Thanks for all the great work on this library.

J

Support non-compile time test runners

Ideally I'd like to be able to include a separate CocoaPod that can add a different test reporter running in Specta. The current method involves adding a runtime flag to the scheme, which is outside the scope of CocoaPods.

+ (SPTReporter *)loadSharedReporter {
  NSString * customReporterClassName = [[NSProcessInfo processInfo] environment][@"SPECTA_REPORTER_CLASS"];
  if (customReporterClassName != nil) {
    Class customReporterClass = NSClassFromString(customReporterClassName);
    if (customReporterClass != nil) {
      return [[customReporterClass alloc] init];
    }
  }

  return [[SPTNestedReporter alloc] init];
}

Ideally, I'd like to be able to change this at runtime. E.g. I could run setSharedReporter in my custom class's load function.

Crash: -[EXPExpect _equal]: unrecognized selector sent to instance

It pretty much crashes on any assertion inside the it block.

rackspace-helios-test.m ->

//#define EXP_OLD_SYNTAX // enable backward-compatibility
#define EXP_SHORTHAND
#import <SenTestingKit/SenTestingKit.h>
#import "Specta.h"
#import "Expecta.h"


SpecBegin(AppDelegate)

describe(@"Starting from the home screen", ^{
    it(@"has a camera button", ^{
        expect(@"foo").to.equal(@"foo");
    });
});

SpecEnd

Console output:

2013-07-25 17:59:41.673 otest[33675:303] Unknown Device Type. Using UIUserInterfaceIdiomPhone based on screen size
Test Suite '/Volumes/Ten/Users/ender/Library/Developer/Xcode/DerivedData/rackspace-helios-fhukmhxhdbzxiofibwoqgdcjvldp/Build/Products/Debug-iphonesimulator/rackspace-helios-test.octest(Tests)' started at 2013-07-25 22:59:41 +0000
Test Suite 'AppDelegateSpec' started at 2013-07-25 22:59:41 +0000
Test Case '-[AppDelegateSpec Starting_from_the_home_screen_has_a_camera_button]' started.
2013-07-25 17:59:41.786 otest[33675:303] -[EXPExpect _equal]: unrecognized selector sent to instance 0xbb99c80
/Volumes/Ten/Users/ender/Projects/rackspace-helios/rackspace-helios-test/rackspace_helios_test.m:0: error: -[AppDelegateSpec Starting_from_the_home_screen_has_a_camera_button] : NSInvalidArgumentException: -[EXPExpect _equal]: unrecognized selector sent to instance 0xbb99c80
  Call Stack:
    0   CoreFoundation                      0x00a0502e __exceptionPreprocess + 206
    1   libobjc.A.dylib                     0x0071ce7e objc_exception_throw + 44
    2   CoreFoundation                      0x00a904bd -[NSObject(NSObject) doesNotRecognizeSelector:] + 253
    3   CoreFoundation                      0x009f4bbc ___forwarding___ + 588
    4   CoreFoundation                      0x009f494e _CF_forwarding_prep_0 + 14
    5   rackspace-helios-test               0x016c145d __33-[AppDelegateSpec SPT_defineSpec]_block_invoke_2 + 141
    6   rackspace-helios-test               0x016c977f runExampleBlock + 1151
    7   rackspace-helios-test               0x016ca8a1 __48-[SPTExampleGroup compileExamplesWithNameStack:]_block_invoke + 209
    8   rackspace-helios-test               0x016cbcbc -[SPTSenTestCase SPT_runExampleAtIndex:] + 444
    9   rackspace-helios-test               0x016cc0a0 __33+[SPTSenTestCase testInvocations]_block_invoke + 80
    10  rackspace-helios-test               0x016cc9db -[SPTSenTestInvocation invoke] + 91
    11  SenTestingKit                       0x20103ed1 -[SenTestCase invokeTest] + 219
    12  SenTestingKit                       0x2010405b -[SenTestCase performTest:] + 183
    13  rackspace-helios-test               0x016cc68c -[SPTSenTestCase performTest:] + 124
    14  SenTestingKit                       0x201037bf -[SenTest run] + 82
    15  SenTestingKit                       0x2010792b -[SenTestSuite performTest:] + 139
    16  SenTestingKit                       0x201037bf -[SenTest run] + 82
    17  SenTestingKit                       0x2010792b -[SenTestSuite performTest:] + 139
    18  SenTestingKit                       0x201037bf -[SenTest run] + 82
    19  SenTestingKit                       0x201063ec +[SenTestProbe runTests:] + 174
    20  libobjc.A.dylib                     0x007305c8 +[NSObject performSelector:withObject:] + 70
    21  otest                               0x00002342 otest + 4930
    22  otest                               0x000025ef otest + 5615
    23  otest                               0x0000268c otest + 5772
    24  otest                               0x00002001 otest + 4097
    25  otest                               0x00001f71 otest + 3953
Test Case '-[AppDelegateSpec Starting_from_the_home_screen_has_a_camera_button]' failed (0.022 seconds).
Test Suite 'AppDelegateSpec' finished at 2013-07-25 22:59:41 +0000.
Executed 1 test, with 1 failure (1 unexpected) in 0.022 (0.022) seconds
Test Suite '/Volumes/Ten/Users/ender/Library/Developer/Xcode/DerivedData/rackspace-helios-fhukmhxhdbzxiofibwoqgdcjvldp/Build/Products/Debug-iphonesimulator/rackspace-helios-test.octest(Tests)' finished at 2013-07-25 22:59:41 +0000.
Executed 1 test, with 1 failure (1 unexpected) in 0.022 (0.023) seconds

Support for Testing Asynchronous Methods

This is an enhancement/feature request, but one that I might be able to contribute myself, depending on time constraints and whether I can get to grips with the Specta codebase.

Currently, I don't know of a 'nice' way to test Asynchronous methods. For example, testing the sample of code from the [AFNetworking readme]:

it("should return results from an HTTP request", ^{
    NSURL *url = [NSURL URLWithString:@"https://alpha-api.app.net/stream/0/posts/stream/global"];
    NSURLRequest *request = [NSURLRequest requestWithURL:url];
    AFJSONRequestOperation *operation = [AFJSONRequestOperation JSONRequestOperationWithRequest:request success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) {
        NSLog(@"App.net Global Stream: %@", JSON);
    } failure:nil];
    [operation start];
});

This code could be difficult to test, and might require calling another method from within the callback, and checking for returned values in a loop. I don't think this is a particularly nice design pattern.

Taking inspiration from the Node.js testing framework Mocha, I propose a new way of enabling Asynchronous testing:

it("should return results from an HTTP request", ^(void(^done)()){
    NSURL *url = [NSURL URLWithString:@"https://alpha-api.app.net/stream/0/posts/stream/global"];
    NSURLRequest *request = [NSURLRequest requestWithURL:url];
    AFJSONRequestOperation *operation = [AFJSONRequestOperation JSONRequestOperationWithRequest:request success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) {
        NSLog(@"App.net Global Stream: %@", JSON);
        expect(foo).notTo.equal(1);
        done();
    } failure:nil];
    [operation start];
});

Optionally, the block time passed to it and other functions will take a callback parameter, called 'done' in this example, which is a block itself that, when called, will remove itself from a list of pending tests.

This design has the disadvantage that it would be very easy to write a test that is never going to complete, but this could be negated with a timeout system of some sort, although I would hope this wouldn't be needed for most cases.

Internally, each time Specta runs a block, it will add a callback block to an internal list, which is able to remove itself again once it is run. Specta will then observe the list for changes and complete the test when it is empty.


I don't know if this is the best way to go about testing asynchronous methods, but I believe it could be better than the current design patterns. I'd be interested in any alternatives that people can propose in the comments, and if something similar to this is already possible it would be great to know about it.

If not, I'd like to implement it in Specta. I've had a brief look at the codebase but I think understanding the structure could take a while. If anyone has any tips or any ideas for implementation please let me know. For example, should the block that takes a callback be the only type of block that is accepted, and all testing would need to be updated (simple, but breaks backwards compatibility, not great solution), or should they be optional and handled with different functions (i.e. if_async(str, block)) etc.

Can not install with cocoapods

Can not install specta with cocoapods:

pod search Specta
Unable to find a pod with name matching `Specta'

pod install
[!] Unable to find a specification for `Specta (~> 0.1.11)`.

I am not sure if it should be reported here or to pods directly.

Cocoapods: 0.27.1
OS X: 10.9

Thank you

dispatch_semaphore_t ignored

Hi,

I'm not sure it this is what is supposed to happen but I'm experiencing the following:
In beforeAll I want to use a semaphore to wait for a login response before continuing.

The code looks like this:

__block dispatch_semaphore_t sema = dispatch_semaphore_create(1);

    beforeAll(^{
        // This is run once and only once before all of the examples
        // in this group and before any beforeEach blocks.

        // Set a timeout of 100 sec
        setAsyncSpecTimeout(100);

        Login *login = [[Login alloc] init];

        [login loginWithUserName:@"user"
                        passWord:@"pass"
                       onSuccess:^(id responseObject) {
                           // Handle successful login
                           dispatch_semaphore_signal(sema);
                       }
                         onError:^(NSError *err) {
                           // Handle error
                             dispatch_semaphore_signal(sema);
                         }];
        dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
    });

Somehow, somewhere, it blocks and sadly I do not have the time to dig down for the issue.
Can you tell me if it's expected behavior?

XCTest does not load test cases unless the 'xctest' branch is used in Podfile

platform :ios, 7.0

target :BudgeTests do
  pod 'Expecta'
  pod 'Specta'
end

Originally had this to set up a new project. But then I realized that the building test did not pick up the test cases I wrote. After trying out bunch of ways, I explicitly listed the xctest branch in Podfile.

platform :ios, 7.0

target :BudgeTests do
  pod 'Expecta'
  #pod 'Specta'
  pod 'Specta', git: "https://github.com/specta/specta.git", branch: "xctest"
end

After cleaning the workspace, running test started to recognize my test cases. Funny thing is I changed it back to my original listing which is

pod 'Specta'

instead of

pod 'Specta', git: "https://github.com/specta/specta.git", branch: "xctest"

and it still works.

I am still trying to figure out what happened.

p.s. - If there is a mailing list for Specta, I will gladly move the conversation over and close the issue. Thanks!

AsyncBlock, NSOperationQueue and expect

I have a problem using Specta with an NSOperation and a block. If you look at the test code below, I use a custom NSOperation which is given a completion block. In this block I called an expect statement that is always false before calling done();

The problem is that Xcode tells me that the test succeeded.

#import <Specta/Specta.h>
#define EXP_SHORTHAND
#import <Expecta/Expecta.h>
#import "YGParseGPXOperation.h"

SpecBegin(GPXImport)

describe(@"GPX Import",^{

    __block NSOperationQueue * testQueue =nil;

    beforeAll(^{

        testQueue = [[NSOperationQueue alloc] init];
        [Expecta setAsynchronousTestTimeout:10.0];

    });

    it(@"should import GPX into context",^AsyncBlock{

        NSManagedObjectContext * context = [[NSManagedObjectContext alloc] init];

        NSString *bundlePath = [[NSBundle bundleForClass:[self class]] pathForResource:@"gpxTest" ofType:@"bundle"];
        NSBundle * bundle = [NSBundle bundleWithPath:bundlePath];
        NSURL * gpxURL = [bundle URLForResource:@"STRASBOURG" withExtension:@"gpx"];

        YGParseGPXOperation * op = [[YGParseGPXOperation alloc] initWithGPXURL:gpxURL inContext:context];

        op.completionBlock = ^(NSError* error){
            expect(1).to.equal(2);
            done();
        };

        [testQueue addOperation:op];

    });



});

SpecEnd

how can I test my library on an iOS6 device?

I've written a small library (https://github.com/BendingSpoons/Stalker - developer friendly KVO and NSNotification​ interface) and I shared it on Github.

I've written some tests using Specta, which by the way I really like.
Now I receive an issue (https://github.com/BendingSpoons/Stalker/issues/2 - by @siutsin) asking me why I didn't support iOS 6.0. The reason is that I didn't spend time testing on iOS6 but the library should work perfectly there since I'm not using any iOS7 API.

I decide to change the deployment target, to update the .podspec, to download the iOS6 simulator and to test it there and to close the issue. When I run the test I discover that specta is built on top of XCTest which I can't use on the iOS6 simulator.

so basically my questions are two:
1- is there any way to run my specta test on iOS6?
2- What would you do if you were me, in this situation?

Integration with test navigator broken in latest version of Xcode

After merging PR #83, you may realize that Specta does not correctly report spec success/failure in the Xcode test navigator.

As of Xcode 6, each test invocation's selector is used to determine the name displayed in the test navigator. Specta uses the same instance method to run each example. As a result, all tests in the same spec had the same name, causing each example to "overwrite" each previous one in the navigator. This caused several issues, including red lines to indicate test failure in Xcode suddenly disappearing when the next example finished running.

This can be fixed by dynamically defining a new instance method for each example, then creating an invocation to execute that instance method.

You can find more details here: https://github.com/modocache/Quick/issues/1

A working implementation of dynamic method definition is here: https://github.com/modocache/Quick/blob/606d77ab12faac00386f24872e33a0347711f0ec/Quick/Core/QuickSpec.m#L33

Release build failure

Following the README's setup instructions, SPTReporter.m fails to compile because runTask is not synthesized. I don't know why, but when Specta is built in Debug, clang is auto-synthesizing (as expected), but something about building for Release seems to result in auto-synthesis being disabled.

Test delegate methods w/ Specta-Expecta

How could I test classes' delegate methods properly ?

    expect(viewC).conformTo(@protocol(xProto));

    expect(viewC).respondTo(@selector(xMethod:));
    expect(viewC).respondTo(@selector(xMethod:));
    expect(viewC).respondTo(@selector(xMethod));

e.g with Mock

    id delegateMock = [KWMock mockForProtocol:@protocol(xProto)];

    [manager setDelegate:delegateMock];

    NSString *response = @"foo";
    [[[delegateMock shouldEventually] receive] managerRepliedWithResponse:response];

    [manager performxMethod];

Thanks in advance!

activelyWaitFor:completion

We often have snapshot tests that need to wait for some long running operation with variable timing, so we added this.

@interface Specta (Sleep)
+ (void)activelyWaitFor:(NSInteger)seconds completion:(void (^)(void))completion;
@end
#import "Specta+Sleep.h"

@implementation Specta (Sleep)

+ (void) activelyWaitFor:(NSInteger)seconds completion:(void (^)(void))completion
{
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0), ^{
        [NSThread sleepForTimeInterval:seconds];
        dispatch_async(dispatch_get_main_queue(), ^{
            completion();
        });
    });
}

@end

Is this something interesting to Specta?

Restore support for custom reporters

XCTest support refactor removed support for custom reporters, including reporting on pending and focused tests. Add this back as discussed in #38.

Current output looks like this:
Executed 78 tests, with 0 failures (0 unexpected) in 1.847 (1.897) seconds

It should be something along these lines:
Executed 2 focused tests, with 0 failures (0 unexpected), 1 pending in 1.847 (1.897) seconds

itShouldBehaveLike, when passed a block, assumes that the sharedExample contains a block capturing NSDictionary *data

The below crashes unless you uncomment the beforeEach block to capture the data dictionary. By the time itShouldBehaveLike attempts to access the autoreleased data dictionary it creates the dictionary has been autoreleased.

SharedExampleGroupsBegin(ExampleGroup)

sharedExamples(@"a group", ^(NSDictionary *data) {

    __block id object;

//    beforeEach(^{
//        object = [data objectForKey:@"object"];
//    });


    it(@"should not crash", ^{
      NSLog(@"you won't get here!");
    });
});

SharedExampleGroupsEnd



SpecBegin(Spec)

describe(@"a spec", ^{
    itShouldBehaveLike(@"a group", ^{
        return @{};
    });
});

SpecEnd

I encountered this bug as I was unsure if, inside a sharedExample, initialization of instance variables belonged in a beforeEach block or in the sharedExamples block itself. Perhaps the documentation should be improved to make the fact that it belongs in beforeEach/it more obvious (although in hindsight, of course, this makes perfect sense).

AppCode doesn't understand beforeEach type correctly

When I start typing...

    beforeEach(<CURSOR>

I want my IDE to autocomplete a block for me. I'm normally able to do this with context and it, where it gives me a block ^{} if I tap Return a few times. But if I do this with beforeEach, this is what I get:

    beforeEach(self);

It should be possible to make beforeEach (and friends) have a parameter type that would suggest to AppCode that it's a block.

Issue building project with Specta and Expecta pods

We're trying to run some tests using the Specta and Expecta pods for our static library, and we're running into some odd issues. When we run pod install, a library is added to our build phases (libPods-PodsTests.a), but the library isn't actually created.

We installed the pods using pod install.

We tried running the test on a test project (that was not a static library) and the test ran fine. It seems that the issue is related to the fact that we're testing a static library.

If we remove the libPods-PodsTests.a from Build Phases, we get an error similar to the one described here. CocoaPods/CocoaPods#316

If we only include OCMock, and remove Speca and Expecta, the tests run as well.

Has anyone seen an error similar to this when testing a static library?

Here's a link to the project we're using to test Specta and Expecta, which includes a static library target, and a regular target: https://github.com/mpdifran/PodsTest

Running a single test / describe block?

Hey there,

Long time Rubyist that just started doing iOS here, and just started using Specta with an XCode 5 project. Thanks for helping to bring readable tests to iOS :)

I like that I can run a single "Spec" block in XCode 5 by clicking the icon to the left of the spec declaration, but that usually encompasses a group of tests (in one or more describe blocks with multiple "it" tests inside that). Is it possible to run a single "it" test, or even a "describe" block", within XCode 5? Running the whole spec file each time I'm working on a single test is really hurting my flow.

Thanks!

Compatibility with test introspection

Hello - xctool, a replacement for xcodebuild which allows for nicer CI integration and command line testing experience - is currently unable to execute Specta tests due to the mechanism used to generate test cases at runtime. They are tracking this issue at facebookarchive/xctool#202 .

Rather than adding code specific to each third party testing library, they suggested trying to find a generic way to identify test cases. If any Specta contributors are interested in helping shape that work, I'm sure they'd be happy for your support.

As a developer using both projects, the ability to run my tests without depending on XCode is very important.

Cheers!

AsyncBlock never calls done()

I created the beforeAll with AsyncBlock bellow to setup and call a web service method, the done() method should be called from the successBlock or the failureBlock.

            beforeAll(^AsyncBlock{
                            NSString *url = [NSString stringWithFormat:@"%@%@", ApiClientBaseUrl, ApiSomeMethod];

            NSBundle *bundle = [NSBundle bundleForClass:[self class]];

            NSString *pathForFile = [bundle pathForResource:@"Fixture01.json" ofType:nil];

            NSData *jsonFile = [NSData dataWithContentsOfFile:pathForFile];

            stubRequest(@"POST", url).
            andReturnRawResponse(jsonFile).
            withHeaders(@{@"Content-Type": @"application/json"});

            AFHTTPRequestOperation *op = [_services someMethod:601 successBlock:^(AFHTTPRequestOperation *operation) {
                            _myObj = [MyObj findFirstByAttribute:@"myObj" withValue:@601];

                            [[_myObj managedObjectContext] save:nil];

                            done();
            } failureBlock:^(AFHTTPRequestOperation *operation, NSError *error) {
                done();
            }];

            [[SyncManager sharedInstance] postItems:@[ op ]];
        });

The API method that I'm calling above, receive a JSON, parse it and save some data via using the MagicalRecord saveToPersistentStoreWithCompletion: method.

        AFHTTPRequestOperation *operation = [[ApiClient sharedInstance] httpRequestOperationWithPath:ApiMethod parameters:nil  success:^(AFHTTPRequestOperation *operation, id JSON) {      
                    NSManagedObjectContext *localContext = [NSManagedObjectContext contextForCurrentThread];

                    NSNumber *myObjId = [JSON objectForKey:@"Id"];

                    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"objId = %@", objId];

                    MyObject *obj = [MyObject findFirstWithPredicate:predicate inContext:localContext];

                    obj = (! obj) ? [MyObject createInContext:localContext] : obj;

                    [obj setupWithDictionary:[JSON objectForKey:@"Result"]];

                    [localContext saveToPersistentStoreWithCompletion:^(BOOL success, NSError *error) {
                                successBlock(operation);
                    }];
                }
                else {
                    successBlock(operation);
                }
            } failure:^(AFHTTPRequestOperation *operation, NSError *error) {
                failureBlock(operation, error);
            }];

I'm not sure why but if I use a block to call the successBlock(operation) the done() method is never called and the tests never are done, they keeping running forever. This just happens in the Test target, inside my default app target I don't have this problem.

Could this be a Specta issue?

Usage of AsyncBlock causing frequent (Unexpected SuiteDidStart) errors

I have been unable to use AsyncBlock reliably. When writing tests and running a single spec, it seems to work fine. However, when I run the whole test suite, I frequently get an error like:

Test Case '-[MyClass MyClass_testing_some_async_task]' started.
        = All tests
MyClass_testing_some_async_task encountered an error (Unexpected SuiteDidStart)

These errors either fail the build as soon as it hits the async spec, or it continues to run.. forever.. running the entire suite over and over and over endlessly until I stop it.

It's worth noting that we have about half of our test suite written in plain old XCTest. I'm not sure if that has anything to do with it or not.

Xcode reports error "(Unexpected TestCaseDidStart)" when running tests

Since upgrading to Xcode 5.0.1 (5A2053), running my Specta test suite is reported as a "Failure" by Xcode, even when the tests themselves are actually successful. The following shows up in the log window:

Running 195 tests:

...................................................................................................................................................................................................

# ----- XCode (OCUnit) Test Output --------------------

Test target MyProjectTests encountered an error (Unexpected TestCaseDidStart)

My Podfile:

platform :ios, '6.0'

pod 'AFNetworking', '~> 1.3'
pod 'SSKeychain'
pod 'NVSlideMenuController'
pod 'Mantle'

target 'MyProjectTests' do
  pod 'Specta', :head
  pod 'Expecta'
  pod 'OCMock'
end

Switchable SPTReporter

There's currently no way to configure the SPTReporter that Specta uses for all tests, since it's hardcoded to SPTDefaultReporter, which itself has lots of behavior hardcoded.

It could be even cooler to customize this based on whether builds are happening through the Xcode GUI or on the command line (but that could be handled with -D flags too).

CC @nerdyc

afterAll block not called with pending example(s) in group (XCTest)

Hi there,

pending examples are included in the group's exampleCount, but are not actually executed (incrementing ranExampleCount). This means that the group's afterAll blocks will not be executed if there is at least one pending example in the group. This means that setting an example as pending will affect the tear down stage of the group, and potentially subsequent tests. This doesn't seem intentional to me. Any clarification?

Keep up the good work!

AsyncBlock crashes

Started using specta, and simply adding the AsyncBlock macro to my tests makes my tests crash. The following code just doesn't work:

describe(@"Tests", ^{
    it(@"should do some stuff asynchronously", ^AsyncBlock { // Here the debugger throws an EXC_BAD_ACCESS
        // Async example blocks need to invoke done() callback.
        done();
    });
});

It's crashing on line 11 of this assembly code:

libobjc.A.dylib`objc_retain:
0x497ad70:  pushl  %ebp
0x497ad71:  movl   %esp, %ebp
0x497ad73:  subl   $8, %esp
0x497ad76:  calll  0x497ad7b                 ; objc_retain + 11
0x497ad7b:  popl   %ecx
0x497ad7c:  movl   8(%ebp), %eax
0x497ad7f:  testl  %eax, %eax
0x497ad81:  je     0x497adb7                 ; objc_retain + 71
0x497ad83:  movl   (%eax), %edx
0x497ad85:  movl   16(%edx), %edx      CRASHING HERE
0x497ad88:  andl   $-4, %edx
0x497ad8b:  testb  $2, 2(%edx)
0x497ad8f:  je     0x497ada5                 ; objc_retain + 53
0x497ad91:  movl   1002945(%ecx), %ecx
0x497ad97:  movl   %ecx, 4(%esp)
0x497ad9b:  movl   %eax, (%esp)
0x497ad9e:  calll  0x497a08c                 ; objc_msgSend
0x497ada3:  jmp    0x497adb9                 ; objc_retain + 73
0x497ada5:  movl   %eax, (%esp)
0x497ada8:  movl   $0, 4(%esp)
0x497adb0:  calll  0x497c8a0                 ; -[NSObject retain]
0x497adb5:  jmp    0x497adb9                 ; objc_retain + 73
0x497adb7:  xorl   %eax, %eax
0x497adb9:  addl   $8, %esp
0x497adbc:  popl   %ebp
0x497adbd:  ret    

Any flags or compiler settings I'm missing? I set the -ObjCflag and I have no compiler errors or warnings. :(

[Xcode 6 Beta] No visible @interface for 'XCTestCaseRun' declares the selector 'recordFailureInTest:withDescription:inFile:atLine:expected:'

Steps to reproduce:

  1. Clone sample workspace: git clone https://github.com/nskboy/SpectaBug.git
  2. Open it with Xcode 6
  3. Hit Cmd + U

Actual behavior:
Build fails with following error:

CompileC /Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-SpectaBugTests-Specta.build/Objects-normal/i386/SPTXCTestCase.o Specta/src/SPTXCTestCase.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Users/ramzes/tmp/SpectaBug/Pods
    export LANG=en_US.US-ASCII
    export PATH="/Applications/Xcode6-Beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode6-Beta.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Applications/Xcode6-Beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c -arch i386 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=gnu99 -fmodules -fmodules-cache-path=/Users/ramzes/Library/Developer/Xcode/DerivedData/ModuleCache -fmodules-prune-interval=86400 -fmodules-prune-after=345600 -Wnon-modular-include-in-framework-module -Werror=non-modular-include-in-framework-module -Wno-trigraphs -fpascal-strings -O0 -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-implicit-atomic-properties -Wno-receiver-is-weak -Wno-arc-repeated-use-of-weak -Wno-missing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wempty-body -Wuninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wint-conversion -Wbool-conversion -Wenum-conversion -Wshorten-64-to-32 -Wpointer-sign -Wno-newline-eof -Wno-selector -Wno-strict-selector-match -Wundeclared-selector -Wno-deprecated-implementations -DDEBUG=1 -DCOCOAPODS=1 -isysroot /Applications/Xcode6-Beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator8.0.sdk -fexceptions -fasm-blocks -fstrict-aliasing -Wprotocol -Wdeprecated-declarations -g -Wno-sign-conversion -fobjc-abi-version=2 -fobjc-legacy-dispatch -mios-simulator-version-min=7.1 -iquote /Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-SpectaBugTests-Specta.build/Pods-SpectaBugTests-Specta-generated-files.hmap -I/Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-SpectaBugTests-Specta.build/Pods-SpectaBugTests-Specta-own-target-headers.hmap -I/Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-SpectaBugTests-Specta.build/Pods-SpectaBugTests-Specta-all-target-headers.hmap -iquote /Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-SpectaBugTests-Specta.build/Pods-SpectaBugTests-Specta-project-headers.hmap -I/Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Products/Debug-iphonesimulator/include -I/Users/ramzes/tmp/SpectaBug/Pods/BuildHeaders -I/Users/ramzes/tmp/SpectaBug/Pods/BuildHeaders/Specta -I/Users/ramzes/tmp/SpectaBug/Pods/Headers -I/Users/ramzes/tmp/SpectaBug/Pods/Headers/Expecta -I/Users/ramzes/tmp/SpectaBug/Pods/Headers/Specta -I/Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-SpectaBugTests-Specta.build/DerivedSources/i386 -I/Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-SpectaBugTests-Specta.build/DerivedSources -F/Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Products/Debug-iphonesimulator -F/Applications/Xcode6-Beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator8.0.sdk/Developer/Library/Frameworks -F/Applications/Xcode6-Beta.app/Contents/Developer/Library/Frameworks -fobjc-arc -DOS_OBJECT_USE_OBJC=0 -include /Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Intermediates/PrecompiledHeaders/Pods-SpectaBugTests-Specta-prefix-chbxxfwvmpzkszexzitsqrnlujvl/Pods-SpectaBugTests-Specta-prefix.pch -MMD -MT dependencies -MF /Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-SpectaBugTests-Specta.build/Objects-normal/i386/SPTXCTestCase.d --serialize-diagnostics /Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-SpectaBugTests-Specta.build/Objects-normal/i386/SPTXCTestCase.dia -c /Users/ramzes/tmp/SpectaBug/Pods/Specta/src/SPTXCTestCase.m -o /Users/ramzes/Library/Developer/Xcode/DerivedData/SpectaBug-dwgvjhmxlodzxxcjihyxixjxozcx/Build/Intermediates/Pods.build/Debug-iphonesimulator/Pods-SpectaBugTests-Specta.build/Objects-normal/i386/SPTXCTestCase.o

/Users/ramzes/tmp/SpectaBug/Pods/Specta/src/SPTXCTestCase.m:142:28: error: no visible @interface for 'XCTestCaseRun' declares the selector 'recordFailureInTest:withDescription:inFile:atLine:expected:'
  [currentTestCase.spt_run recordFailureInTest:currentTestCase withDescription:description inFile:filename atLine:lineNumber expected:expected];
   ~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

beforeEach/afterEach only apply to current group

If I have nested describe groups, I'd expect that beforeEach and afterEach would apply to every spec at every level below the current group. But they only apply to the current group. Is there a reason you see not to run them at every nested level?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.