Cristobal: Behaviour Strategy Implementation, 3 weeks

[alexander-lopez-s]

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 ...
  • [x] Write: Your own solution by remixing the ones you studied.
  • [x] Explain: How the other solutions inspired yours; what ideas did you take from them? what ideas did you not take?
  • [x] 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.
• [x] 🐣 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:
  • [ ] Reading Docs: You can understand what the function is supposed to do by reading it's JSDoc description.
  • [ ] Writing Tests: You can write test cases before there is a function to test.
  • [ ] Writing Functions: You can write one function that passes the test cases you have prepared (even if it's just 1 test case!).
  • [ ] 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.
  • [ ] Formatting
  • [ ] Linting
  • [ ] 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.

---

[alexander-lopez-s]

Week 1

I Need Help With:

• I am not confident with the throwError() function, I will research on the internet for more information.

What went well?

• I am very confident creating functions to resolve a basic problem presented by Edabit website.
• I can use describe/it/expect.toEqual functions and I understand that they are useful to test our implementations.
• I can write passing test cases to describe it's behavior. (Basic tests).
• I have successfully learnt the process to create a file test.js and run it in the console to check if the test fails or passes.
• Completed 15 exercises on Edabit. Going to open another account as the free trial is over.

What went less well?

• I am not clear why do we need Sandbox or any other testing platforms. Are they pre-created libraries?

Lessons Learned

• Testing is really important to avoid errors in our code, it is also important to document what the function does (parameters an arguments) and what is expected as result.
• When describing functions, we need to be clear and use plain English so that our colleagues can also understanding it.

Sunday Prep Work

• I am going to pick up some more exercises from Edabit and try testing.

[danielhalasz]

I am not confident with the throwError() function, I will research on the internet for more information.

Evan will add some examples with throwing errors next week, in the meantime you can also try changing the functions to return a certain output instead..and then expect that output in the test.

I am not clear why do we need Sandbox or any other testing platforms. Are they pre-created libraries?

testing is not built into JS, and there are different tools to do unit-testing. One of the most popular ones is maintained by Facebook and is called Jest. In the repo, we use Jest for testing. So you can check out the Jest documentation to read more about it.

[alexander-lopez-s]

Week 2

I Need Help With:

• I still have problems understanding the use of arguments and parameters. Why do we sometimes leave the parenthesis empty function speed (){ and sometimes we declare variables inside? function speed (distance, time){?

• What is the difference between console.log(); and return();?

What went well?

• I am now confident with the throw error function and Math.round();

• I understand the difference between toBe and equalTo. toBe uses strict equality, toEqual uses property equivalence. expect(0).toBe(-0) will pass but expect(0).toEqual(-0) will fail.

• I can test my implementations (though I do not know the syntax by heart, I know it follows this pattern: describe, it and expect.

• I completed the doctor exercise. See the test here!

What went less well?

• I tend to create a function first and then, to write the tests. I know this is not a good practice but it becomes challenging for me referencing to something I do not see.

• I wrote a second solution for the doctor test using nested functions, however; the tests did not pass. Going to share the code in Discord, maybe you can give me feedback.

Lessons Learned

• There are multiple testing frameworks like Jest, Jasmine, Mocha, we can use whatever we want, but we need to install the dependencies first.

• I am a bit more efficient with unit testing.

Sunday Prep Work

• I am not good at debugging with VS code, have practiced but it is confusing. There is too much ongoing at the same time. I will try practicing with VS with a very basic exercise.

[danielhalasz]

• I still have problems understanding the use of arguments and parameters. Why do we sometimes leave the parenthesis empty function speed (){ and sometimes we declare variables inside? function speed (distance, time){?

well depends what the function is doing..does it take any input values or not? for example, we could have:

const myFunction1 = () => {
  console.log('hello Cris');
}

const myFunction2 = (name) => {
   console.log('hello' + name);
}

now, if you call the first function, it will always console.log hello Cris but the second one will say hello "name"

myFunction1();
myFunction1('Dorian');
myFunction2('Dorian');
myFunction2('Cris');

[danielhalasz]

• What is the difference between console.log(); and return();?

I assume you mean executing something like console.log(123) and writing inside a return statement inside a function like:

const myFunction3 = () => {
    return 123;
}

now, console will print 123 to the console...while return will pass on the number 123 to whatever is calling myFunction3.. let's say:

const myFunction3 = () => {
    return 123;
};

console.log(myFunction3());

[danielhalasz]

• I understand the difference between toBe and equalTo. toBe uses strict equality, toEqual uses property equivalence. expect(0).toBe(-0) will pass but expect(0).toEqual(-0) will fail.

you seem to understand it..but toBe is NOT strict equality..toEqual is 🙂

[danielhalasz]

• I tend to create a function first and then, to write the tests. I know this is not a good practice but it becomes challenging for me referencing to something I do not see.

the goal is not to have an implementation..with the TDD approach..the goal is to make sure that certain input scenarios will have a certain outcome.. so you just want to write down.. giving an input string should pass a number array should fail..or something like that..HOW that happens..can be dealt with later..

[danielhalasz]

• There are multiple testing frameworks like Jest, Jasmine, Mocha, we can use whatever we want, but we need to install the dependencies first.

yes, although Jest is already a dependency in the HYF repo, so enough to do npm i

[danielhalasz]

• I am not good at debugging with VS code, have practiced but it is confusing. There is too much ongoing at the same time. I will try practicing with VS with a very basic exercise.

it is basically the same as Chrome Dev Tools, just a slightly different interface, so can be confusing at first :) in VSCode..you won't be able to debug stuff that involves the DOM, of course..

[alexander-lopez-s]

const myFunction3 = () => {
    return 123;
}

So, return will work inside the function while console.log will show the returned result in the console!

[alexander-lopez-s]

It's clear as water!!!! Thanks for these examples.

[alexander-lopez-s]

Week 3

I Need Help With:

• What is the rule for declaring variables outside the scope? Do we always need to do that?
• Why do we need to install canvas? npm i canvas
• Is it always a good practice to keep our arrays untouched? Like, making a copy of the original one and saving it in a variable?
• How can we test functions when we are getting the values from the user directly?

// voltage = current * resistance
function calculateVoltage (){
    let current = document.getElementById("current").value;
    let resistance = document.getElementById("resistance").value;
    let voltage = 0;`
if (current =< 10 && ....... 

What went well?

• I am becoming more confident with arguments and parameters but still a little bit hesitant. Is is optional to declare parameters?

• This week, I have learnt how to merge two arrays into one using the concat function.

• I also practiced shorting an array with the .length = 0 function.

• I played a little bit with the random function as well.

• So far, I tested and implemented a solution for the sorting numbers in an array exercise.

• I created for my very first time an arrow function and it is working perfectly (though I am not a fan of those at all).

• I also used the import and export features in JS, it is really cool, I thought it was more difficult but it resulted to be easy to link them.

What went less well?

• Long functions are difficult to read, I need a lot of comments to understand what is going on.

Lessons Learned

• I am confident with tests. Still I do not know how many type of cases do we have, like in this week exercises I saw a test with variables.

describe('sortNumbers sorts an array of numbers', () => {
  describe('sorts positive numbers', () => {
    it('whole numbers', () => {
      const expected = [0, 1, 2, 3, 5];
      const received = sortingNumbers([5, 2, 0, 3, 1]);
      expect(received).toEqual(expected);

Sunday Prep Work

• I am currently solving the rest of the exercises, will continue with the flow and discuss my results with my team.

[danielhalasz]

• What is the rule for declaring variables outside the scope? Do we always need to do that?

There is no rule, it depends on what you want to achieve, if you want to use it outside of the scope or not.

• Why do we need to install canvas? npm i canvas

you do not need to install canvas manually like this.. it is just a peer-dependency for one of the npm packages, that gets installed for some HYF repos.

• Is it always a good practice to keep our arrays untouched? Like, making a copy of the original one and saving it in a variable?

again, depends on your goal..but in general yes, it can be a good practice to do that.

• How can we test functions when we are getting the values from the user directly?

this is a really good question. well, we can create test cases for all possible scenarios that could end up in to input field..and the are also tools to help with stubbing&mocking data. this is beyond the scope of what we are doing now, but you can look into it, if you are interested.

• Is is optional to declare parameters?

sure, absolutely. it depends on what the function is doing, if it accepts any input parameters..

• I also practiced shorting an array with the .length = 0 function.

why would you do this?

• I created for my very first time an arrow function and it is working perfectly (though I am not a fan of those at all).

great job! try to get used to them, as that is the current standard :)

• Long functions are difficult to read, I need a lot of comments to understand what is going on.

indeed, writing good documentation is very important and often overlooked

• Still I do not know how many type of cases do we have, like in this week exercises I saw a test with variables.

can you pls rephrase this question? I am not sure I understand it.