Behavior-driven development Automated Test Proposal

[StriderHND]

Hello,

As for looking into the future of the project for the iOS development of the dev.to app, I really like to bring to the table what direction we should take as far as case testing for new functionality or the current code base for the app.

There is XCTests,
Xcode native Case Testing Tool its pretty great but it takes some time to learn if you are new to native iOS development.

And there is Quick this is more friendly to those are more related to javascript development it's pretty similar to (JEST / Chai) and have pretty nice features that would make to make testing more easy. here is the installation guide if you wanna make some tests

I would really like to discuss what coverage percent should be acceptable (I would like to propose that 90% it's a good threshold, 100% is desired)

And any other rules should be applied how the test should be wrote and structured.

Any other proposals are welcome!

[benhalpern]

Given where we are currently at with this project: A shortage in needed features, I could see putting a good deal of focus into testing and have a high test coverage goal.

Quick strikes me as possibly better for the project because we're not a super experienced native company, but I could see the benefit of XCTests as well because this project itself is definitely very native in what it's supposed to do. (More responsibilities for native bridge than lots of different complicated features at the moment)

I'm cool with you rolling with whatever you feel best and we'll get behind. @chickdan and maybe @Ceri-anne may have some other thoughts. Happy to follow with wherever we land.

We also need to get Travis working properly again, cc: @maestromac

[Ceri-anne]

I don’t have any experience with Quick but the app is reasonably simple so XCTest and XCUITest should be pretty straight forward.

I wrote a test for the navigation policy in ViewControllerTests and it didn’t need much setup.

Happy to learn something new though :-)

[StriderHND]

Given where we are currently at with this project: A shortage in needed features, I could see putting a good deal of focus into testing and have a high test coverage goal.

Quick strikes me as possibly better for the project because we're not a super experienced native company, but I could see the benefit of XCTests as well because this project itself is definitely very native in what it's supposed to do. (More responsibilities for native bridge than lots of different complicated features at the moment)

I'm cool with you rolling with whatever you feel best and we'll get behind. @chickdan and maybe @Ceri-anne may have some other thoughts. Happy to follow with wherever we land.

We also need to get Travis working properly again, cc: @maestromac

Yes that's the main proposal I know that we are not a a super experienced native company that's why I look into Quick.

I don’t have any experience with Quick but the app is reasonably simple so XCTest and XCUITest should be pretty straight forward.

I wrote a test for the navigation policy in ViewControllerTests and it didn’t need much setup.

Happy to learn something new though :-)

Yes the project right now is very straightforward so XCTest and XCUITest should do the work but if we get into more complex features in the feature XCTestAsserts are not very clear in some ways that's why is the proposal of Quick.

@chickdan have any thoughts about this?

[chickdan]

Admittedly I don't have a lot of experience testing iOS to be familiar with the drawbacks of XCTests. I glanced over the two frameworks and I agree we should at least use Nimble but I'm not sold on Quick, at least not yet.

[StriderHND]

Thanks for the input guys, after give more thought to this I think we should stick with XCTest for the simplicity that offers to setup.

Most of the test right now are not so complex, but even when the native side gets more responsibility we can extend over that.

[benhalpern]

Sounds great @StriderHND

[StriderHND]

Hello,

To follow up this proposal, I'll be uploading soon the guidelines, so we can discuss them and make changes if need, is nothing complex but discussion is needed.

@benhalpern I'll be sending to you the draft I've for you to review.