Cover the app with tests

[fonorobert]

There are many modules in the app that are built in a universal way. At least these should be covered with tests.

I don't think this is a very high priority and I understand the difficulties in writing tests for an already developed, large app, but I still think it would be a good idea.

[gvilarino]

Agree. We never find the time but we will start doing this after 1.0

[gvilarino]

Btw we're planning on using mocha for testing but are open to suggestions.

[fonorobert]

I was about to suggest mocha too. I tried it with the chai assertion library, worked great for me.

[AaronNGray]

mocha and chai seem to becoming the defacto standards for most of the major node and js projects.

supertest (https://github.com/visionmedia/supertest) too is good for testing node REST API's

On 28 June 2015 at 20:49, Robert Fonó notifications@github.com wrote:

I was about to suggest mocha too. I tried it with the chai assertion library, worked great for me.

— Reply to this email directly or view it on GitHub https://github.com/DemocracyOS/app/issues/943#issuecomment-116321013.

[Jacodom]

What about mocha + zombie?

[mjlescano]

Didn't know Zombie, looks awesome for integration tests :open_mouth:.

[AaronNGray]

Yeah, Zombie looks cool for that :)

On 7 July 2015 at 18:19, Matias Lescano notifications@github.com wrote:

Didn't know Zombie http://zombie.js.org/ [image: :open_mouth:], looks awesome for integration tests.

— Reply to this email directly or view it on GitHub https://github.com/DemocracyOS/app/issues/943#issuecomment-119273947.

[Goutte]

May I suggest Cucumber.js as the top layer for integration testing ? It supports Gherkin specs, which are the best kind of specs anyone can write right now.

I've been (ab)using Gherkin for a while now, never looked back. For an ambitious project like this, I truly believe this is a must-have. Especially as some of the specs might be later subjected to democratic polls.

Hence, it makes sense to provide the non-technical community with a way to better understand and even help refining the specs, or expose behavioral bugs.

And you still can use whatever assertion/execution library you want under the scenes ; it's just elegant and decoupled packaging for the specs themselves !

And, one last thing, if (some would say when) you decide in a bunch of years to rewrite the frontend using another language (Dart, anyone?), you get to keep the Gherkin specs, and development gets a pretty nifty boost.

---

Writing the specs is a very good hackathon theme ; if you decide to do one, count me in ! (IRC, hangouts, mumble, even the cursed skype, so many means of commuting these days!)

[gvilarino]

zombie looks really awesome.

@Goutte I just checked Cucumber. While it sure is nice for a pm-ish role to describe a test in the typical agile/scrum way of writing a story (As X I want to W happen when Y because Z), I feel that it may be a bit too much demanding on maintaining bolierplate just for the sake of itself. In my experience, the cleaner the testing code, the better. Test code should be extremely lightweight easy to maintain and change, I think.

[Goutte]

@gvilarino I thought like you before I actually tried it. The specs are cleaner and lighter when written in Gherkin, and those are not feelings, but hindsight.

Still, do as you feel is right, but heed my warning : good specs matter.

[gvilarino]

Yeah, I was trying to bring to the table what things matter when chosing an automated testing solution.

I do agree that good specs matter. A lot, actually. Do you have any real-life examples for a medium sized application on how to organise testing under Cucumber and Gherkin?

[Goutte]

Diaspora comes to mind. It's Ruby, but the file tree looks exactly the same with javascript.

There's also a bunch of examples, but they don't look very ... well ... let's say complete, at first glance.

---

And BDD is not only about automated testing. It's deeper than that ; it also commits the lazy devs to write better code, the busy devs to write clearer code, and helps crystallizing the objectives of the project.

[Goutte]

After re-reading some of the Diaspora specs, I've observed that they are not a good example on how to write Gherkin. They might even be used as an example on how to not write them. Too much coupling between CSS classes or HTML attributes and the specs. This is not good spec design. Nope.

Look at Enrique Amodeo Rubio's example instead, he knows what he's doing.

[martsa1]

I'm about to be developing a Node based webapp at work. Whilst we've settled on Mocha for the moment, I discovered Jest today for unit testing, I haven't had the chance to try it out yet though. Zombie and Supertest both look awesome, I just found Nightwatch as well.

[gvilarino]

:+1: to nightwatch - That should be our testing solution for health-checking our core paths.

[sachalifs]

We'll start that in a couple of weeks. First testing the models, then the db-api and then the api.

Tests for the client side code we'll come in later.