The section on Bad practices is somewhat weak. The comments only point to performance and legibility issues with eval and with.
In 4 - Loops, the assertions are not too well chosen. You're testing that...
...while, to be a better exemplification of what while and for do, a more correct assertion would be to...
expect(currentNumber < 5).toBe(false); // or more generally, expect(condition).toBe(false);
That way we're actually asserting on the contract of while/for not on the effects that happened.
The optimization proposed by 'You can minimize memory access inside for loops' has been demonstrated to not be such an optimization.
The for-in example is under Performance optimizations but the argument is not related to performance.
In 14 - Objects Functionality some of the tests are all over the place. 'Properties can be functions' does not actually test that a property is a function at all, but instead it tests the behaviour of thisValue when actually calling the function on the object. Also, it can be particularly confusing the comment that //'this' keyword always refers to the owner Object of the function as it introduces some mysterious "owner object" concept which goes unexplained (and is probably wrong anyway). The comment that //'this' keyword references the person's object doesn't help much either.
The test 'To iterate through an object we need to use the for-in loop' introduces iterating through object properties with for-in but obfuscates the assertion too much because the test is not very good. It also seems it would make more sense to put this test in 13 - Objects than here.
15 - Object prototype has some problems too.
The assertions for 'you can use valueOf to retrieve the primitive type associated with an object' don't actually relate to "retrieving a type", but instead assert something on the workings of == vs ===. Also, saying expect(fiveNumber.valueOf()).toBe(5) is related to retrieving the primitive type of an object is, to say the least, confusing.
Saying that 'you can use valueOf to retrieve the type of an object' (emphasis is mine) is quite confusing. More so when the assertion shows that person (which we would probably think is of type Person) is shown to apparently be of type Object.
In general, I'm getting the impression that most if not all of the mentions on the word type are either wrong or confusing, when not both.
The rest of the tests in this section have some additional issues both in the wording and in the content.
Section 17 - Prototypes is, quite frankly, a mess. 'Properties can be functions' doesn't even make sense in the description itself and the assertions it performs don't seem to clarify at all what that description is supposed to mean. The test 'Adding a new function into the Strings Prototype' should instead be named after the comment it has right before it (You can add base functionality to all objects of the same type). I don't even know what 'You can create generic objects and build all the inherited objects with such properties' means. 'You can use prototype chaining to reuse functionality' doesn't seem to be showing any reuse of functionality.
Some of this may be a symptom of what I said that I feel a test driven approach doesn't really help for some of these explanations.
The only thing really worth in 19 - General performance is the bit about using DOMFragments.
In 26 - Truthy values this piece here...
var definedVar = value ;
value = (definedVar) ? true : false;
...could be confusing. It may seem to be saying that we're expecting the result to be true just because we're testing a defined variable. While it is actually true because definedVar has a value of true.
I suggest to have License in this repository. Good for tutorial have a license. You can add LICENSE file to your repository. LICENSE can fit to you is MIT License. If you want me to add the license, I happy to add that.