Week 2 - TDD

[sohilpandya]

@Joshua-Ronan-Phillips @sohilpandya we think it should be week 1.

WEEK 1 -

• Workshop - intro to TDD basics basics basics. difference between unit/integration frontend/backend etc. need to create a good workshop.
• Morning Challenge - like Nikkis tests
• Project - Something like the stopwatch but slightly longer so it can last the two days.

[katpas]

@hdrdavies

• Morning challenge incorporating testing. e.g. give interlinked function to de-bug, show how to debug by console-logging output. After 1/2 hours on this show how tests would have been written to prevent the need for this. Shows the importance of testing in practice.
• To start with Javascript should be very simple functions and focus on the testing not new javascript concepts.
• Ping Pong development (maybe on the morning challenge) but also on projects.
• Whole week on testing, and how to set up/install the testing frameworks and which ones to use/why.
• Back-end testing (week 2) before node introduced (week 3). We could set up a sandbox for them to write tests in.
• Use different testing frameworks at different points in the course - Mocha etc. ???
• TDD also links into writing good code, smaller functions with one job are easier to test.

[thegsi]

@katkelemen @thegsi

• Problem TDD was introduce server side at same time as TDD.
• Introduce front-end TDD separately back-end TDD. More detailed and hand-holding at this stage.
• Learn about back-end testing being provided with a project based on eg 20 tests. Write the code to pass the tests which will be the project. Ta Da!
• Only a couple of tests for each project written before the implementing functionality (pure TDD). Possibly other tests written later.

[rug1]

Frontend testing - simpler workshop than stopwatch, maybe write tests for simple maths functions that people can already visualise what will be the output.

[Conorc1000]

Conor and Matt

• Explain the difference between Integration and unit testing.
• Have an exercise where you complete the code to pass the tests (to bridge the gap between code wars tests).
• Can show examples of when you add code to pass a test, it can break a previous test (to stress the importance of test).
• How tests tell a story, can you describe what each function does in sudo code just by looking at the test.

[jackcarlisle]

@Jbarget + @jackcarlisle

Day 1: Intro into TDD

• What is TDD?
• Q Unit example
• Synchronous & Asynchronous testing
• Unit testing vs integration testing

Day 2: Workshop -TDD Building a simple program using Q Unit

• Give a simple problem to solve (easier than the stopwatch) using TDD

Day 3: Workshop - Asynchronous in more detail

• Building on day 2 workshop

[sohilpandya]

@mantagen @Joshua-Ronan-Phillips @Conorc1000 @rug1 @naazy

WEEK 1.

TDD and introduction to methods/functional programming.

[katpas]

@jackcarlisle @Jbarget @hdrdavies @katpas

• Controversy over use of q-unit, do we need to learn front-end testing? @katpas @hdrdavies opposed. Is this the point of the course? Full stack testing?
• @jackcarlisle @Jbarget Front-end testing is easier, should introduce it as a baby step first.

[rug1]

Agreed by all of FAC6

Week 2 Structure

Day 1 - Intro to TDD (as Jack and Justen have suggested above). Learning objectives. Day 2 - Workshop on writing and passing simple functions using qunit. Showing what ping pong is. Project - Stopwatch project. Tests need to pass. Good CSS on stopwatch.

Morning challenges - array methods and functional programming introduction.

[nelsonic]

@rug1 simpler TDD Project, simple maths function ... https://github.com/dwyl/learn-tdd#scenario-vending-machine-change-calculator-micro-project ?

[sohilpandya]

@nelsonic we will be using the simple vending machine one as part of a workshop on monday.

[iteles]

@sohilpandya The only comment I made before the planning started yesterday was that if we don't introduce TDD in week 1, week 2 is already too late in my experience, it gets put to one side as 'too much work' after the week it's brought in.

[iteles]

On the readme, I would suggest that teaching people the mechanics of TDD before actually explaining what TDD is (down as day 2 in your suggested timetable) goes against what FAC6 discussed multiple times in the stop go continue - when the readme days provide context, they should be on the Monday. (Conversely, when the workshop days provide a more guided understanding, they should be on the Monday - but that's not the case here).

And a question: Are you still planning on using the dwyl TDD tutorials as we used for FAC6? Do they need to be iterated on (I know you were simplifying Natalia's Git tutorial for week 1 for example)?

[rjmk]

@iteles I'm not sure we can really say that 'week 2 is too late in [our] experience' seeing as far as I can tell there has never been a successful inculcation of TDD on any FAC! On FAC 5 there was a bit of BDT (Badge Driven Testing) but not a whit of Test Driven Development. There was also quite a bit of harmful mocking and general weirdness in pursuit of coverage badges.

And it doesn't look like FAC6 are doing much testing

[sohilpandya]

@iteles Regarding TDD being week 1, the consensus in the room was that we were overwhelmed with week 1 as it was, but we still think TDD is a must, so we have made the whole of week 2 focused around TDD, and shifted rest of the course back a week. we are hoping that this will get TDD ingrained into how they work. :smile:

[nelsonic]

@rjmk totally agree that "Badge Driven Testing" is probably not the best idea (at least until people _understand why_ they are testing their code...) ... harmful mocking indeed ... :disappointed:

Yes, we do not have much experience with TDD in FAC because FAC3 did zero unit/functional/acceptance testing during their course, FAC4 barely did any testing and some of FAC5 did not embrace the idea of testing their work because they did not feel the pain of not having tests.

But, in our professional experience, once a team/project is launched without tests its rare to adopt the TDD discipline because there is never "enough time" to write tests retrospectively for existing code ... and as a result most people "out there" don't test their work ... :sob:

Ask @ronanyeah @benjaminlees or @adamdiy who have gone out into the industry and seen/felt the pain of working on projects without tests ... maybe @ronanyeah should come in and tell FAC7 how much of his life has been wasted trying to build on code without tests.

[rjmk]

@nelsonic If the concern is that people will not retroactively test their code, that doesn't seem to give much reason to introduce TDD in week 1. We start a new project every week anyway!

[nelsonic]

@rjmk the concern is based on the painful experience of working with (too many) people who refused to write tests on the grounds that it "takes longer" and then leave the team/company with a shoddy codebase ...

Similar to documentation unless its captured in a Readme while the work is being done, it will rarely be done retrospectively ...

[rjmk]

@nelsonic Good examples re: readmes! :laughing:

Re: testing, I think I'm misunderstanding the concern. It sounds something like

if we don't teach testing in the first week, no one will learn TDD because many people refuse to write tests because it "takes longer"

but that doesn't sound like I'm getting your gist.

I'm not saying that it's not true that TDD needs to be taught in the first week. I'm just saying that the evidence we have from previous FACs doesn't really have much to say about whether that's true or not.

Obviously you have a lot of other relevant experiences and I recognise that I am speaking from a position of relative ignorance. I would still like to see why the first week of FAC is a special opportunity for teaching TDD.

[nelsonic]

@rjmk === :heart: