Adapting this as a new resource for FAC 11

[oliverjam]

Hi @nelsonic!

@finnhodgkin and I are mentoring Testing Week so we're currently going through all the workshops we did.

We're going to be switching from QUnit to Tape (as per this proposal), so we need to re-work lots of the existing material.

We love this workshop and think it's a great resource as it is, so we wouldn't really want to change it. The vending machine change challenge fits TDD really well, so we'd love to keep using the concept.

We're wondering if you'd be happy with us creating a new workshop inspired by this one, but trimmed down and using Tape instead?

[nelsonic]

@oliverjam all good questions, apologies for not making these clear sooner.

The question of which testing library/framework comes up before and I'm still not convinced that using Tape is simpler than QUnit given that this tutorial is a single .html file.

Our mission when writing a beginner-friendly tutorial is to assume as little as possible before people start, are you aware if tape can be run without Node.js?

To be clear I think tape is better for Node.js testing that's why the "next step" after learning TDD is https://github.com/dwyl/learn-tape but in order to lower the "barrier" having the single .html file for this tutorial has proved very successful.

With regards to creating a new workshop Is there a specific advantage to creating a new workshop instead of re-using this one? Is there an area we aren't already covering? This tutorial has been used by F&C people since F&C5 and hundreds of people in the community but we would love to improve it if you have time.

[oliverjam]

@nelsonic I think the distinction is that although this is a great workshop for introducing testing, we don't think it fits with the overall week.

To clarify: we decided that QUnit wasn't a great way to introduce testing, because lots of our cohort found it confusing to learn a methodology that isn't really used again after this week. It also encouraged some bad practices as it gives you access to the DOM (lots of people were writing tests to check that their headings had the correct text for example).

QUnit also requires copying a large amount of boilerplate HTML to get it working, which I don't think is any less confusing than being told to run npm install -D tape.

assume as little as possible before people start

I think this is a great goal for a general beginner tutorial, but when we control the entire learning environment I think we can be a bit more specific about what and how we teach people. Students will have to learn npm by week 4 anyway, and it's not like they suddenly become more capable at that point, so we don't think it's unreasonable to teach it at this point instead.

The advantage to creating a new workshop is that it would use Tape. I don't think there's anything missing from this workshop, it's just using a different technology to the rest of our planned week. We don't think this workshop should be changed to remove QUnit, which is why we were suggesting creating a totally new one with a similar coding challenge, but reworked to use Tape.

EDIT: Apologies I just realised that the workshop you linked above for learning Tape is actually pretty much exactly what we want. Do you think we could use that in the course instead?

[nelsonic]

@oliverjam I'm confused. Are you suggesting that learning about testing/TDD should be ignored until "Node.js Week"?

The purpose of the "Learn TDD" tutorial was to teach testing as early as possible without requiring Node.js. "Learn TDD" has one index.html file with 33 lines of HTML which is arguably not a "large amount of boilerplate", given that most people learning JS should already be familiar with HTML and loading a stylesheet or external script ... (or is this an invalid assumption...?) Each line of the index.html is either explained in the readme or with an in-line comment.

We have tested this tutorial on people at Codebar who barely know any HTML and they have learned TDD in a couple of hours.

Throw in Node.js before people are .ready() and they get "overwhelmed" really fast.

The original idea behind teaching Testing (which was an afterthought before F&C 5) was to cover Testing as early as possible (in F&C 5 we covered it on the second day of Week 1! i.e. long before node.js) We instilled good habits early and that whole cohort has reaped the benefit. (there are a few who chose to work for companies that don't write any tests, but that's sadly beyond the control of F&C mentors; we did our best to give them good habits.)

https://github.com/dwyl/learn-tape is designed to follow on seamlessly from "Learn TDD"... did you spot something specific missing or unclear?

To be clear: I don't think there should be a "testing week" or even a "testing day" ... I think testing should be learned from "Day 0" and every day should be testing day. Otherwise people rapidly descend into chaos/bad habits which are hard to break.

Everyone should have the 10 Step Workflow "drummed" into them from the start:

• Identify the need/requirement or pain point.
• Write a user story (as a GitHub Issue) with acceptance criteria checklist.
• Estimate how much time is required to build the story/feature.
• Convert the user story into a test case (or multiple test cases)
• Write code to pass the test case(s)
• Commit code on a branch referencing the user story on GitHub.
• Create Pull Request with feature referencing story
• Submit PR to peers for review.
• Reviewer comments, requests changes and ultimately merges into master.
• Deploy (using continuous deployment)

Rinse. Repeat. Collect $200.

[iteles]

I'm with @nelsonic here, learning tape before you know anything about node will be pretty confusing.

You are of course more than welcome to include any dwyl workshops/tutorials as part of the course @oliverjam and if you feel they could be simplified once they have been tested, PRs are welcome!

[oliverjam]

@nelsonic Our cohort decided not to teach QUnit, and to teach Tape instead (here is the proposal). That's the only major change we want to make to Testing Week (Week 2 of the course).

The current plan is to go over the basics of npm at the start of the week, show the students how to set up Tape and then let them get on with writing tests. Why do you feel like learning about npm in Week 2 would be overwhelming, but not in Week 4?

If there's significant push back on using Tape in Week 2 then that's a conversation that needs to happen asap, because we've already finished our scheduled curriculum planning time.

[sohilpandya]

@oliverjam this proposal was not discussed at the meeting last week and there have been concerns raised by @des-des about extra dependencies in that issue too. https://github.com/foundersandcoders/master-reference/issues/253

It's not about learning npm in week 2 vs week 4. It's about trying to have something to build upon on a week by week basis. Otherwise, we would just introduce all the topics in the first couple of weeks as workshops and then let you go off and do whatever you wanted.

The focus of the week is testing and there are bound to be more questions about npm rather than testing if we introduce that in week 2.

I would recommend you use still use qunit.

[des-des]

@iteles @nelsonic @sohilpandya @oliverjam

I am not sure this issue is the place to challenge fac10's decision to use tape instead of qunit in week 2.

It seems to me oliver asked a pretty straight forward question. And ended up being drawn into a tangential discussion, rather than be able to focus his energy on achieving his goals.

This issue has been open for 20 days, https://github.com/foundersandcoders/master-reference/issues/253 and no one has objected.

[finnhodgkin]

@sohilpandya I disagree with the notion that teaching introductory npm in week 2 would disrupt the curriculum's week by week momentum. It's not as if we're advocating a Node core server in week 2, we're just suggesting we keep the same testing framework throughout to keep consistency. FAC10 had multiple SGCs with complaints about QUnit and Blanket.js; and it was also one of the most raised issues at our first curriculum planning session.

Plus, we actually currently do introduce npm in week 2. Blanket.js requires live server to work (as well as just not working with newer versions of QUnit).

[finnhodgkin]

Ee just noticed @des-des replied after you. Shall we move this conversation to the issue he mentioned?

[iteles]

Again, @oliverjam, you're more than welcome to use any dwyl tutorials and workshops to teach at Founders & Coders. :blush: Opening issues (and subsequent PRs) on simplifications, suggestions and feedback are most appreciated so we can continue to build on both the dwyl and Founders & Coders communities' needs 👍

Let's move the discussion on whether or not QUnit should be part of the curriculum back to https://github.com/foundersandcoders/master-reference/issues/253.

EDIT: Additionally, a little more context provided here: https://github.com/foundersandcoders/master-reference/issues/253#issuecomment-306054818

[YvesMuyaBenda]

@nelsonic The discussion on the whole is not really my thing to be involved in; but on a more general level, your comments on the purpose and context in which the tutorial was created in was interesting, and makes me wish all the tutorials had that kind of metadata.

[nelsonic]

@oliverjam / @finnhodgkin, yes please move/keep any technology (opinion-based) discussions to where they can be debated. 👍 Questions related to the content of this tutorial should continue to be raised as issues here. ✅

tl;dr

I selected QUnit on the basis that it is "neutral" i.e. unopinionated. But as with all decisions, there's always going to be someone who has a "better" idea. (which usually isn't "better", it's just someone's opinion based on incomplete information.)

I originally wrote this tutorial using Mocha which was the early leader in Node.js Testing; Mocha is still way more "popular" than Tape, Jest or Ava but that does not make it "better"! After making the time to understand Mocha in depth, I realised that it uses Globals for everything and promptly stopped using it.

I have nothing against people using Tape. What I object to is people flagrantly copying dwyl's tutorials without any attempt at attribution (this has happened several times in F&C ... it's infuriating but no point "fighting" it.)

Why Not Jest (i.e. the "Facebook Stack") ?

If we teach everyone to use Jest we'll be one step closer to getting people jobs at Facebook. 🙃 That's clearly what some people want because they don't care about selling out people's personal data to the highest bidder or selling elections to corporate interests. I don't have time to argue with those people anymore. Watch the BBC Documentary on how Facebook effectively sold Donald Trump the US Election: https://www.google.com/search?q=facebook+panorama+documentary&tbm=vid

While it pains me that people "graduating" from F&C have virtually nothing to distinguish themselves from all the others who have been brainwashed into believing that the Facebook "stack" is somehow "better", I don't have time to "argue" with anyone anymore;

I've clearly stated my technology choices in https://github.com/dwyl/technology-stack based on 7 years of using Node.js/JavaScript in Production at several companies and realising that JavaScript is a actually not the best at anything it does ... it's a compromise I simply don't have to make!

@des-des FYI: I have totally given up on "objecting" to issues on Founders & Coders repositories because those discussions are not based on "shoshin" but rather on fashion and the opinions of people who have been brainwashed by Facebook's marketing hype.

Sadly, most people simply don't care that Facebook enriching themselves by selling your personal data to corporate interests and greedy politicians. 😞 Ignoring the fact that there is objectively better tech than anything in Facebook's "Stack", each time we use something they make/own we are directly supporting them by "voting" with our usage.

I find it much easier to just continue getting my work done and if the internet finds my output useful, that's great, but if not, I'm not the slightest bit bothered.

I intend to fix this problem once-and-for-all as soon as I finish working on client projects and have time to dedicate to completely re-writing all the dwyl tutorials into a cohesive book with extensive examples.