I wrote a lot of tests: Unit tests, integration tests, good tests, bad tests, flickery tests, and so on. Unit tests are always my favourite because they are easy to reason, simple to write and quick to run. But, they are less effective when the goal is building a GUI application. Especially web applications.
Modern GUI applications, web included, has very little business logic to be implemented. It usually has very heavy UI codes and an army of reactive engines to translate user actions to HTTP calls, then translate the HTTP results to UI reactions. The more fragile part is the message passing and translating, which involves many different aspects. And this calls for integration tests and it requires a lot of mocking.
Modern GUI applications, web included, has very little business logic to be implemented. It usually has very heavy UI codes and an army of reactive engines to translate user actions to HTTP calls, then translate the HTTP results to UI reactions. The more fragile part is the message passing and translating, which involves many different aspects. And this calls for integration tests and it requires a lot of mocking.
I ended up writing long integration tests that cover a complete action to reaction, the pipe. For example, if users submitted a search term (action), then a list of items is produced (reaction).
I usually do not start a test with a UI event, but start from the point of receiving a UI event. In this case, something happened in the GUI which cause the start of the pipe. And I do not verify my test result with a visual element check, e.g. `$('searchResults').text`.
I test only the pipe. The GUI application may decide to use this pipe when a text box is updated, or the enter key is pressed, or 5 seconds have passed. For the result of the pipe, this one is harder to judge when it should end. As long as it is not an HTTP response, I would be content.
I usually do not start a test with a UI event, but start from the point of receiving a UI event. In this case, something happened in the GUI which cause the start of the pipe. And I do not verify my test result with a visual element check, e.g. `$('searchResults').text`.
I test only the pipe. The GUI application may decide to use this pipe when a text box is updated, or the enter key is pressed, or 5 seconds have passed. For the result of the pipe, this one is harder to judge when it should end. As long as it is not an HTTP response, I would be content.
Not involving the GUI give me a lot of flexibility in writing and running the tests. Not having to start any test drivers are already a big plus. This is not ideal, but it is the most balanced way to use tests to help the development. Not to the point of writing too many useless, or worse, rigid tests. Also not to the point of having too few tests I have better eyeball everything for every code change.