Tests

[tristen]

I can definitely help out here too but after the merge of backbone we need to set up tests based on the groundwork you started in master.

[edrex]

i'd love to be able to submit bugs in terms of a new failing test

[rebelzach]

I'd also love to start writing more tests. It'd probably be good to have a brief tool discussion. Do we want to move forward with phantomjs/mocha? Should we use BDD specs as well to help manage functionality growth?

[mikemorris]

@rebelzach I'd love to get more tests written to help confirm what's broken and prevent new breaks moving forward. I'd like to stick with mocha, but I'm indifferent to phantomjs - feel free to use it or scrap it, whichever makes more sense. BDD, Node's default assert module or any other assertion lib is fine as long as all tests are written in the same style for consistency.

[anandthakker]

@prose/contributors I'd love to get going on some refactoring and deep bugfixes, but it would definitely be better to get some key regression tests in place first.

I'm happy to do the legwork of getting the test infrastructure humming, but before I get started, I wanted to see what people think about handling the github API in the tests: we could either (a) mock the gh API or (b) use an actual repo as test fixture.

I'm leaning towards (a), but I can see arguments both ways. Thoughts?

[zzolo]

(a) makes sense to me. If for some reason (b) is needed, it won't be that hard to move to it later.

[mikemorris]

Yes, yes, yes to regression tests (or tests for currently broken functionality) first. I don't have much experience with mocks, but that seems like a sensible approach. It wouldn't catch API changes, but the GitHub API is stable and well-documented so I'm not too concerned about that.

As far as a testing framework, I'm still largely indifferent (whatever is best for the job), but I've been using tape lately and really enjoy it.

@anandthakker You should chat with @dereklieu as I know he's starting some work on adding tests to Prose as well, would be great to get both of you on the same page.

[dereklieu]

Yes @anandthakker it'd be great to work on testing with you. I'm also pretty indifferent to the testing platform we use, but if we do go with mocking the API, then the test framework should have affordances for doing that. Do you have a test infrastructure that you think would work well with prose, or that you're particularly comfortable with?

[anandthakker]

Thanks for the responses!

@dereklieu I'm flexible too, framework-wise. I've never used sinon.js, but it looks quite promising for mocking (particularly the fakeServer bit). Looks like it works well with mocha/chai, which is what I'd probably default to if you agree...?

I think some parts of Prose are going to be difficult to test without a bit of reorganizing/modularizing... but we can start simple and see.

[mikemorris]

I think some parts of Prose are going to be difficult to test without a bit of reorganizing/modularizing

This is definitely the case, I started a little experiment breaking out the published logic into a separate module, I'll get it pushed up to a branch soon.

[anandthakker]

@mikemorris Cool. I've been thinking that the "file" model/collection in particular ought to be broken into smaller pieces, and also that it would be great to encapsulate the jekyll-specific logic.

[anandthakker]

I've put some framework in place (c7dc5ebd05d42532674776a0386f6a99c507e488). My plan now is to start working on the priority issue queue, but for each one, before working on the fix, I'll add one passing (i.e. regression) test and one failing test that describes the bug. If other @prose/contributors joined me on that, I bet we could have a nice set of tests in no time :pray:

[tristen]

Awesome

[mikemorris]

I'll add one passing (i.e. regression) test and one failing test that describes the bug

Awesome, this sounds like a great plan.

[dereklieu]

:+1:

[hdgarrood]

This sounds like it should be really helpful. Thanks! :)