Angular 缓存view后出现无法找到view(‘can not find view’)错误


问题:grunt对js/css/html进行合并,压缩,发布后,在index页面出现’can not find view’错误


  1. 查看html文件确实存在
  2. 查看grunt配置,是否包含相关html文件(这里用grunt-angular-templates插件
  3. 将html文件换存到$templateCache中)
  4. 查看合并后的script.js文件是否已经cache html文件
  5. 查看压缩后的script.js文件是否包含需要的html文件
  6. 查看缓存的html文件路径和在directive中调用的文件路径是否一致




Angular 缓存view后出现无法找到view(‘can not find view’)错误

Atom 显示/隐藏指定文件

基于git 管理的项目中,都会用到gitignore文件,它会自动忽略一些配置文件或者第三方依赖,例如.git, bower_components, node_modules等。在用Atom开发项目时,有时候希望显示或者隐藏gitignore指定的文件,或者自己指定的文件。


1. 点击菜单 Atom -> Preferences,或者快捷键 Cmd+逗号(Mac),进入Atom配置。

2. 如果希望自己指定隐藏或显示的文件,点击Core,在Ignored Names 下录入想忽略的文件名。screen-shot-2016-11-21-at-15-54-203.  点击Packages,输入 tree-view或者直接滚动到tree-view包位置,点击SETTINGS,勾选“Hide Ignored Files”和“Hide VCS Ignored Files”,它会即时生效。前者控制步骤二指定的文件,后者控制git等VCS (version control system) 指定的文件。



Atom 显示/隐藏指定文件

Javascript’s null vs undefined

If we draw a comparison between ‘null’ and ‘undefined’, we will get following result:

null  !== undefined     true
null  !=    undefined    false
null ==    undefined   true
null === undefined   false
typeof null                  “object”
typeof undefine”      “undefined”

Undefined means a variable has been declared but has not yet been assigned a value (defined). Or we can take it as default value of variables given by JS engine until it is assigned value. (think about missed arguments when function is called, absent property of an object). It means nothing.

Null is an assignment value. It can be assigned to a variable as “no value” or “empty object”. It has to be assign programmatically but not default set. (think about DOM operation returns an object reference either a element or null). It means a value

In conclusion, both null and undefined mean nothing, are falsey (type coercion), so null abstractly (loosely) equals to undefined, however their types are different, so null strictly does not equal to undefined.

Javascript’s null vs undefined

Mock VS Stub

I believe the biggest distinction is that a stub you have already written with predetermined behavior. So you would have a class that implements the dependency (abstract class or interface most likely) you are faking for testing purposes and the methods would just be stubbed out with set responses. They wouldn’t do anything fancy and you would have already written the stubbed code for it outside of your test.
A mock is something that as part of your test you have to setup with your expectations. A mock is not setup in a predetermined way so you have code that does it in your test. Mocks in a way are determined at runtime since the code that sets the expectations has to run before they do anything.
Tests written with mocks usually follow an initialize -> set expectations -> exercise -> verify pattern to testing. While the pre-written stub would follow an initialize -> exercise -> verify. The purpose of both is to eliminate testing all the dependencies of a class or function so your tests are more focused and simpler in what they are trying to prove.

Mocks vs Stubs = Behavioral testing vs State testing
According to the principle of Test only one thing per test, there may be several stubs in one test, but generally there is only one mock.
Test lifecycle with stubs:
Setup – Prepare object that is being tested and its stubs collaborators.
Exercise – Test the functionality.
Verify state – Use asserts to check object’s state.
Teardown – Clean up resources.
Test lifecycle with mocks:
Setup data – Prepare object that is being tested.
Setup expectations – Prepare expectations in mock that is being used by primary object.
Exercise – Test the functionality.
Verify expectations – Verify that correct methods has been invoked in mock.
Verify state – Use asserts to check object’s state.
Teardown – Clean up resources.
Both mocks and stubs testing give an answer for the question: What is the result?
Testing with mocks are also interested in: How the result has been achieved?

Stub is simple fake object. It just makes sure test runs smoothly.
Mock is smarter stub. You verify Your test passes through it.

For replacing a method with code that returns a specified result.
A stub with an assertion that the method gets called.

Stubs don’t fail your tests, mock can.

Stub is like making sure a method returns the correct value
Mock is like actually stepping into the method and making sure everything inside is correct before returning the correct value.

A Stub is an object that implements an interface of a component, but instead of returning what the component would return when called, the stub can be configured to return a value that suits the test. Using stubs a unit test can test if a unit can handle various return values from its collaborator. Using a stub instead of a real collaborator in a unit test could be expressed like this:
unit test –> stub
unit test –> unit –> stub
unit test asserts on results and state of unit
First the unit test creates the stub and configures its return values. Then the unit test creates the unit and sets the stub on it. Now the unit test calls the unit which in turn calls the stub. Finally the unit test makes assertions about the results of the method calls on the unit.
A Mock is like a stub, only it also has methods that make it possible determine what methods where called on the Mock. Using a mock it is thus possible to both test if the unit can handle various return values correctly, and also if the unit uses the collaborator correctly. For instance, you cannot see by the value returned from a dao object whether the data was read from the database using a Statement or a PreparedStatement. Nor can you see if the connection.close() method was called before returning the value. This is possible with mocks. In other words, mocks makes it possible to test a units complete interaction with a collaborator. Not just the collaborator methods that return values used by the unit. Using a mock in a unit test could be expressed like this:
unit test –> mock
unit test –> unit –> mock
unit test asserts on result and state of unit
unit test asserts on the methods called on mock

Every class or object created is a Fake. It is a Mock if you verify calls against it. Otherwise its a stub.

Stub: a dummy piece of code that lets the test run, but you don’t care what happens to it.
Mock: a dummy piece of code, that you VERIFY is called correctly as part of the test.

According to

Mock VS Stub

Unit Test Terms

The “system under test” is short for “whatever thing we are testing” and is always defined from the perspective of the test. When we are writing unit tests the system under test (SUT) is whatever class (a.k.a. CUT), object (a.k.a. OUT) or method(s) (a.k.a. MUT) we are testing; when we are writing customer tests, the SUT is probably the entire application (a.k.a. AUT) or at least a major subsystem of it. The parts of the application that we are not verifying in this particular test may still be involved as a depended-on component (DOC).
The term SUT means also a stage of maturity of the software, because a system test is the successor of integration test in the testing cycle.

There are very few classes that operate entirely in isolation. Usually they need other classes or objects in order to function, whether injected via the constructor or passed in as method parameters. These are known as Collaborators.

Test Double
The generic term he uses is a Test Double (think stunt double). Test Double is a generic term for any case where you replace a production object for testing purposes.
There are five types of TDs, which are dummy, fake, mock, stub, spy.

It is used when a parameter is needed for the tested method but without actually needing to use the parameter.
Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
It’s not intended to be used in your tests and will have no effect on the behaviour.

It is used for providing the tested code with “indirect input”.
Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.
Think of a Stub as a step up from a Dummy. It implements a required Interface, but instead of missing method bodies, it usually returns canned responses in order for you to make assertions on the output of the SUT.

It is used for verifying “indirect output” of the tested code, by asserting the expectations afterwards, without having defined the expectations before the tested code is executed.
Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
A Stub could also be used to maintain state, and make assertions, when a Stub does this it is also known as a Test Spy.

It is used as a simpler implementation, e.g. using an in-memory database in the tests instead of doing real database access.
Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).
The simplest way to think of a Fake is as a step up from a Stub. This means not only does it return values, but it also works just as a real Collaborator would.

It is used for verifying “indirect output” of the tested code, by first defining the expectations before the tested code is executed.
Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don’t expect and are checked during verification to ensure they got all the calls they were expecting.
Whilst all of the other types of Test Double build on each other, gradually adding more functionality, Mocks are something totally different.
Until now, all of our test doubles have made assertions on state. Mocks are test doubles that make assertions on behaviour.
Typically, using a Mock will consist of three phases: Creating the instance, Defining the behaviour, Asserting the calls.

Classical vs Mockist
There are two schools of thought on Test Doubles: Classical, and Mockist. Put simply, people who use the Classical style only use Test Doubles when there is a compelling reason to do so, such as external dependencies, whilst a Mockist would mock everything, all the time.
The advantage of using the Classical style is that you don’t have to worry about internal behaviour of your objects, which is what OOP is all about. When you change an object and it’s collaborators your tests will still pass, but this comes at the sacrifice of speed and isolation.
The advantage of using the Mockist style is that your tests are isolated and can run much faster, but at the sacrifice of coupling your tests to the internal behaviour of your objects and their collaborators.



Unit Test Terms

Fix ul height 0 when li with float

In some cases, float property is added to li element to make ul display in a line, however it causes ul has 0 height, which may cause element overlay around there. This can be explained by W3C as

Floats, absolutely positioned elements, inline-blocks, table-cells, table-captions, and elements with ‘overflow’ other than ‘visible’ (except when that value has been propagated to the viewport) establish new block formatting contexts.

In a block formatting context, each box’s left outer edge touches the left edge of the containing block (for right-to-left formatting, right edges touch). This is true even in the presence of floats (although a box’s line boxes may shrink due to the floats), unless the box establishes a new block formatting context (in which case the box itself may become narrower due to the floats).

It can be fixed by using following ways:

  • add overflow: hidden; to ul element
  • add clearfix to ul
  • add display: inline-block; to li
  • add float to ul
  • assign specific height to ul
Fix ul height 0 when li with float