Maha: Behavior - Strategy - Implementation, 3 Weeks

[MahaLubbad]

my fork of module repository

Behavior, Strategy, Implementation

Learning Objectives

Priorities: 🥚, 🐣, 🐥, 🐔 (click to learn more)

There is a lot to learn in this repository. If you can't master all the material at once, that's expected! Anything you don't master now will always be waiting for you to review when you need it. These 4 emoji's will help you prioritize your study time and to measure your progress: - 🥚: Understanding this material is required, it covers the base skills you'll need to move on. You do not need to finish all of them but should feel comfortable that you could with enough time. - 🐣: You have started all of these exercises and feel you could complete them all if you just had more time. It may not be easy for you but with effort you can make it through. - 🐥: You have studied the examples and started some exercises if you had time. You should have a big-picture understanding of these concepts/skills, but may not be confident completing the exercises. - 🐔: These concepts or skills are not necessary but are related to this module. If you are finished with 🥚, 🐣 and 🐥 you can use the 🐔 exercises to push yourself without getting distracted from the module's main objectives. ---

1. Remix

Practice studying and remixing other people's solutions to coding challenges. Create your own solutions by mixing and matching pieces from other people's code.

• 🐣 Reconstructing: You can reconstruct a variety of solutions to the same challenge when they are presented as parsons problems.
• 🐣 Analyzing: You can analyze a function written at your level. This includes:
  • [x] Behavior: Write documentation, test cases and use cases to describe the function's behavior.
  • [x] Strategy: Describe the function's strategy using plain english.
  • [x] Implementation: List the language features in a function and explain how each one is used.
  • [x] Small Changes: You can think of 2+ changes to the function's implementation that would not change it's strategy.
• 🐣 Remixing You can analyze several solutions to the same challenge then ...
  • [ ] Write: Your own solution by remixing the ones you studied.
  • [ ] Explain: How the other solutions inspired yours; what ideas did you take from them? what ideas did you not take?
  • [ ] Analyze: Complete a write-up your own solution as though someone else wrote it.

2. Write

• 🐣 Function Design:
  • [x] Writing Tests: Given a working function, you can write passing test cases to describe it's behavior.
  • [x] Writing Functions: You can design multiple solutions to the same code challenge, keeping notes about different experiments you tried along the way.
• [x] 🐣 Generating Documentation: You can write a JSDoc comment for your solutions and run a script to generate markdown documentation.
• [ ] 🐣 Fuzz Testing: You write solutions that pass randomly generated test cases.
• 🐥 Test Driven Development: You can solve open-ended, ambiguous coding challenges at your level:
  • [x] Reading Docs: You can understand what the function is supposed to do by reading it's JSDoc description.
  • [x] Writing Tests: You can write test cases before there is a function to test.
  • [x] Writing Functions: You can write one function that passes the test cases you have prepared (even if it's just 1 test case!).
  • [x] Refactoring: You can improve your function's implementation without failing any test cases that were passing.
  • [ ] Iterative Development: You can repeat the TDD process until you are satisfied with your test cases and solution.
• [ ] 🐔 Code Golf: Write your solutions with the fewest characters possible! This won't help you write readable code, but it will make you think deeply about JS, your strategy and implementation.

3. Review

• 🐣 Continuous Integration: You can check your code's quality before pushing so your CI checks all pass.
  • [x] Formatting
  • [x] Linting
  • [x] Testing
• [ ] 🐣 Code Review: You can use a checklist to give a thorough, positive and constructive review of your classmates' solutions.
• [ ] 🐔 Code Coverage: You can explain what code coverage is, why it's important, and can write unit tests with 100% code coverage.

---

[MahaLubbad]

Week 1

• [x] I have pushed my progress to my fork of solution-write-up

I Need Help With:

• I still feel confused about the tests >> we write them before the coding but applying these tests will be after the implementation (after writing the code)?!
• I couldn’t pass the tests in my sandbox file and even the example tests didn’t run or pass with me.

What went well?

Writing the readme file. Solving daily exercises.

What went less well?

Passing the tests in our challenge .

Lessons Learned

• Describe function behavior by using JSDoc (documentation), unit tests and use cases.
• Strategy is the way to solve the problem before writing the code, by  flow charts, diagrams …
• Implementation is transferring strategy into reality by coding it.

Sunday Prep Work

Not yet .

[vkoldus]

Hi @MahaLubbad, for the problem where you can't run the tests, can you please describe what problems are you having? If there is an error you see in your VSCode, can you paste it here?

About the testing before coding, indeed, it is a bit confusing. For me there are three main advantages:

• What I call "Empathy"
• Isolated environment
• Self organization

What I mean by empathy is this. By writing the tests first, you are putting yourself in the shoes of your colleague or a customer who will use your function, without knowing how it's implemented. This is very important. People will not read the inside of your function. They will only look at its name, parameters and if you're lucky the documentation. That's it. By not knowing the implementation yourself, you can think about it as they will. How should it be named so that it's clear what it's doing? What should be the parameters? What should the function return when I put in some data? What if I put in some nonsense by accident? All this reasoning is more successful, when done without knowing the actual implementation.

The advantage of isolated environment will become even more clear when you will try to work on something a bit bigger than just one function. Imagine you are working on a big web app and you want to code just one small calculation. Without starting with the test, you would have to navigate through the application to a place where the function you want to implement is used and put everything in the right state. This can include logging in, going to the right part of the site and possibly inserting some data through the UI. Every time you want to try a new implementation, you would need to do that again. With unit testing you can do all this much more quickly. Now of course, you can get all these advantages by starting with one or two tests and adding more later, but then you would be loosing the "empathy".

Finally, self organization. Software development is a fast paced environment. People are often under pressure to deliver as much as possible as quickly as possible. This forces us to take shortcuts wherever we can. One of the first things people start to skip are tests and documentation. If we do that, we very often regret that later, but at the given moment, we get a quick win. We finished sooner and we can deliver. By starting with the tests, we minimize the risk that we decide to skip the testing later because something else comes in or we forget. That also happens. People forget. It's a way how to trick ourselves into having good test coverage even when we don't have that much time.

Is it more clear like that? If you have some more specific question, hit me on Slack, I'll be happy to answer them.

[MahaLubbad]

Hello @vkoldus Thank You very much for your great clarifications 🙏 And for the testing problem , our coaches helped me to fix the error on Sunday.

[MahaLubbad]

Week 2

• [x] I have pushed my progress to my fork of solution-write-up

What went well?

• Solving easy exercises.
• Solving medium exercises.

What went less well?

Difficulty with dealing with NaN

Lessons Learned

• Jsdoc documentation.
• Jest unit testing.

Sunday Prep Work

I will start soon .

[MahaLubbad]

Week 3

Group Forked Repo

What went well?

Writing function and tests.

What went less well?

Struggling with passing jest tests by using export and import with separated files for functions and tests.

Lessons Learned

• Jest tests
• Dealing with ESLint and their rules.
• Prettier
• Code coverage

Sunday Prep Work

Not yet .