1. Proposed Outline Revised
2. dsb thoughts/ideas/questions
2.1. Is our idea basically to put the structure of this book into an interactive course that uses JavaScript instead of Rails as its base?
2.2. How will we have these two ideas interact
2.2.1. The idea of TDD and the pedagogical backing and the productivity buy in
2.2.2. The testing program langauge and syntax themselves
2.2.3. I think we want them to flow in and out of each other. Coming together and then seperating (is there a name for that pattern/relationship?
3. TDD Project Overview
3.1. SYLLABUS
3.1.1. 1) Introduction
3.1.1.1. Essential questions
3.1.1.1.1. What is testing?
3.1.1.1.2. What is automated testing?
3.1.1.1.3. What is the purpose of testing?
3.1.1.1.4. How does it benefit the team, product, process, and codebase?
3.1.1.1.5. What are the costs and benefits of testing?
3.1.1.1.6. What are the tradeoffs between manual and automated testing?
3.1.1.1.7. When to test and when not to test?
3.1.1.2. Topics
3.1.1.2.1. Use guiding questions to interact with website
3.1.1.2.2. Can you find the bugs in the website?
3.1.1.2.3. How would you start to fix these bugs?
3.1.1.2.4. Run a test suite and compare to what you found
3.1.1.2.5. Regression
3.1.1.2.6. Customer service reports bug
3.1.1.2.7. When you don't need to test
3.1.1.3. Conclusion
3.1.1.4. Required Resources
3.1.1.4.1. Intro (Context Item)
3.1.1.4.2. Why test (lesson, quiz, project)
3.1.1.4.3. Setup environment (Lesson or Article)
3.1.1.4.4. When you don't need to test (Article)
3.1.1.4.5. Off-platform project:
3.1.1.4.6. Setup testing environment on your computer
3.1.2. 2) Fundamentals of Testing
3.1.2.1. Essential questions
3.1.2.1.1. What is a ‘good’ test?
3.1.2.1.2. What are the fundamental functions of <TBD testing framework(s)> and how are they used?
3.1.2.1.3. What is TDD and how does it work?
3.1.2.1.4. What are unit and integration tests, and when should each be used?
3.1.2.2. Topics
3.1.2.2.1. What's a good test
3.1.2.2.2. Manual repl testing
3.1.2.2.3. Introduce technology (Mocha)
3.1.2.2.4. When to write a test
3.1.2.2.5. Use TDD with unit tests to develop calculator (all in one layer -- Calculator.XXXX)
3.1.2.2.6. Introduce integration tests
3.1.2.3. Required Resources
3.1.2.3.1. Intro (Context Item)
3.1.2.3.2. Manual testing (Lesson, quiz, project)
3.1.2.3.3. What's a good test (Article)
3.1.2.3.4. Testing with Mocha (Lesson, quiz, project)
3.1.2.3.5. When to write a test (Article)
3.1.2.3.6. What is TDD + red-green-refactor (Article)
3.1.2.3.7. TDD with Mocha (Lesson, quiz, project)
3.1.2.3.8. Integration tests (Lesson, quiz, project)
3.1.2.3.9. Off-platform project
3.2. Section 1
3.2.1. Why test?
3.2.2. Setup environment
3.2.3. When you don't need to test
3.2.4. Setup testing environment on your computer
3.3. Section 2
3.3.1. Manual testing
3.3.2. What's a good test
3.3.3. Testing with Mocha
3.3.4. When to write a test
3.3.5. What is TDD + red-green-refactor
3.3.6. TDD with Mocha
3.3.7. Integration tests
3.3.8. Unit + integration test of simple HTML/CSS/JS application
3.4. Section 3
3.4.1. Testing pyramid
3.4.2. Outside-in
3.4.3. Testing: Features
3.4.4. Testing: Server
3.4.5. Testing: Database
3.4.6. Refactor a green suite
3.4.7. Outside-in with TDD (Lesson, quiz, project)
3.4.8. How testing integrates into a real development process
3.4.9. Build full-stack testing suite without React
3.5. Section 4
3.5.1. Client-server interaction
3.5.2. Testing: Requests
3.5.3. Testing: React JSX
3.5.4. Testing: React State
3.5.5. Where React fits into pyramid
3.5.6. Refactor submission to JS request, view to JSX, and add notion of "read comments" to blog.
3.6. Section 5
3.6.1. Build testing suite for full-stack web application
3.7. Context Items
3.7.1. Context Items for content
3.7.2. Context for unit intros and conclusions
3.7.3. Context items for Pre-req Unit
3.8. 1
4. Fundamentals of TDD ThoughtBot Course
4.1. write a test - make it past - write a test-make it past
4.1.1. distinct from test less approach. Where you save testing for the end if you have time which you never do
4.2. WHAT IS TEST DRIVEN DEVELOPMENT
4.2.1. Test-Driven Development is a development technique where you write a failing test and then create code to make that test pass.
4.2.1.1. This process is sometimes called a red-green-refactor cycle with the failing tests being the "red" state, passing tests being the "green" state, and the refactoring step occurring after tests pass, where code can be confidently improved.
4.3. if you wrote a test for every feature then you know every feature works
4.3.1. otherwise you don't have anythign ot tell you when to stop
4.3.2. leads to bloated code and over development.
4.4. confidence to make changes to big chunks of the code
4.5. "I've heard testing is hard.'
4.5.1. maybe a little, but it's important. And it saves time in the long run and allows you to confidently maintain and change your code base.
4.5.2. So it is more work to do test driven development, but it's important and worth it work. And if you have a full suite of regression tests, you can be confident in contiuing to change your code base