Make sure to understand the difference between unit tests and integration/system tests.
A unit test deals with a part of the code which is granular enough to be able to narrow the search of a bug if the unit test fails. There is no long polling here. No REST calls. No AJAX. No database access. REST, access to files, database calls and all those operations which are exterior to the tested code are mocked, i.e. a mock or a stub is created for everything your tested unit needs.
If you're testing the filtering of products, you'll use a stub which will replace the database and provide sample products to use for testing purposes.
If you're testing whether the purchase action decreases the quantity of the product in the warehouse, you'll use a mock which will ensure that it was indeed called by the tested unit and asked to decrease the quantity.
Depending on the ecosystem and from person to person, the strictness of what can be in an unit test and what cannot vary a lot: you may indeed see some skillful persons using for example database access in their unit tests, while others will find it awful. It's up to you to determine how much you're a purist, and what common sense dictates to you, given your language of choice and the community.
Once you have unit tests covering the critical parts of the application, you can start assembling the parts. Interfaces between different components of a system are good places for mistakes, so the integration of components needs to be tested as well. This is what integration tests are about.
Once all bricks are combined into a system, this system may not be functioning as expected, even if integration tests haven't revealed anything wrong. Here, system tests come into play.
Note that those tests are not the only tests available for a developer or a QA department. There are functional testing, acceptance testing, etc. For example, one of the tests which would hopefully become popular consist of taking a diff image of a webpage, and inspect the possible differences in order to detect both purely client-side rendering as well as server-side processing mistakes.
All this testing may serve for regression testing, i.e. the testing which enables you to ensure a change haven't broken anything. Combined with continuous integration, it enables you to identify exactly what was broken and when, and makes it possible to use continuous delivery, those tests mitigating the risk for a broken revision to be automatically pushed into production.