Tests unitarios y su diferencia con los tests funcionales http://chimera.labs.oreilly.com/books/1234000000754/ch03.html#_unit_tests_and_how_they_differ_from_functional_tests
A menudo la línea que separa los tests es un poco confusa. La diferencia principal es que los test funcionales van a comprobar la aplicación desde fuera o desde el punto de vista del usuario, mientras que los tests o pruebas unitarias van a comprobar la aplicación desde dentro, desde el punto de vista del programador. Entonces, seguiremos estos pasos: 1) Empezamos escribiendo un test funcional que va a describir la funcionalidad desde el punto de vista del usuario. 2) Lógicamente como no tenemos nada de código, este test funcional va a fallar. Empezaremos a pensar qué es lo que tenemos que tener para que no falle (pero acordaros de pensar en bajo nivel, es decir, no nos vale pensar que para que no falle
Semantic versioning Semver.og
"connect": "1.8.7". The 1 indicates the Major version, the 8 indicates the Minor version and the 7 is the Patch level. You don't have to specify the exact version number in your package.json. We don't exactly have to put our exact version number, we can use ranges, for instance: "connect": "~1" that means npm will work as long as the version is >=1.0.0 <2.0.0, this is dangerous because any changes to the Minor version could break your App. We can make it a little safer by doing this: "connect":"~1.8" that npm will install anything that >=1.8 <2.0.0, but we could have problems because for instance there are usually name changes in API from Minor to Minor versions. The safest way to define a range is: "connect":"~1.8.7". This means Npm will install only the patches which means: >=1.8.7 <1.9.0 It shouldn't break your application.
Functions are first class objects in Javascript Helephant.com
This means that functions are a special type of object that can do all the things that regular objects can do, like any other variable. A function is an instance of the Object type. Check it out:
alert(nameFunction instanceof Object);. It can have properties and has a link back to its constructor method: foo.food = "text"; alert(foo.food); alert(foo.constructor);. You can store the function in a variable: var storesfunction = foo; and then execute it: storesfunction() which is going to execute in the end: foo(). You can pass the function as a parameter to another function: foo2([foo]). Or you can return the function from a function: function foo(){ return 'text'; } var variable = foo(); variable();. In fact, object methods are notheing special in JS. They just are properties that contain a function instead of something like a string variable or int value: var fooObject = { name: "object-foo", age: 34, sayHi: function(){ alert("Hi!");}}
The 3 Watch Depths of AngularJS Tero Parviainen Blog - The Three Watch Depths of AngularJS
Hay tres formas de estar controlando un valor en el $scope. El primero es registrar un Watch sobre referencias (de hecho se usa el operador ===):
$scope.$watch(_,_,false);, así podremos controlar asignaciones como esta: $scope.users = newUsers. La segunda forma es registrar un Watch en una colección (bien sea arrays, objetos como arrays y objetos en general): $scope.$watchCollection(_,_), controla al poner, quitar, reemplazar o reordenar los objetos de la colección pero no los valores de dichos objetos. Para controlar el tercer nivel de profundidad tenemos los $scope.$watch(_,_,true) y que controlará cualquier cambio en los valores de cualquier objeto. Esta tercera opción resulta ser la que más carga tiene. Algunos ejemplos de estos tres tipos de profundidad los encontramos directamente en AngularJS, para las referencias por ejemplo: ngModel, ngClass, ngIf, ngSwitch, $location, ngBind. Para las colecciones: ngRepeat. Para los valores: ngClass y ngStyle.
Differences between Assert, Expect and Should in testing Stack overflow - What is the difference between assert, Expect and should in chai
The 3 interfaces present different styles of performing assertions. Ultimately, they perform the same task and some users prefer one style over the other. However, there are some technical considerations. 1) The
Assert and Expect interfaces DO NOT modify Object.prorotype, whereas Should does. So they are better choice in an environment where you cannot or do not want to change it. 2) The Assert interface supports custom messages just about everywhere. For example: assert.isTrue(foo, "foo should be true"). The message will be output together with the failed assertion should it fails. This does not have an exact equivalent in Expect or Should. The Expect form which is analogous to isTrue in the Assert interface is: expect(foo).to.be.true. You can work around this limitation by testing for equality rather than truth: expect(foo).to.equal(true, "foo should be true"). Note that assert.isTrue(foo) and expect(foo).to.be.true and foo.should.be.true all output the following if you don not use a custom message and foo === 1: AssertionError: expected 1 to be true. To sum up, while the Expect and Should interface are nicer to read, it is not like one interface is more naturally informative than the oter when an assertion fails.
topic of the idea or text to remember link text
text and ideas to remember
topic of the idea or text to remember link text
text and ideas to remember