Hacker News Reader

Comment by edwinnathaniel | Hacker News Reader

I'm also interested to see a mid-size scale SPA project that has excellent unit-testing and integration-testing.

I've read a lot about how JS can make programmer productive, I've also read a lot how code can be succinct and all that jazz because of JS, but I have _never seen_ a well-architected, well-documented, well-automated-tested non-todomvc SPA codebase.

This isn't a sarcasm or criticism but a serious and legitimate "ASK" because I'm working on a large-scale SPA project that's hard to write automation test other than Selenium.

I'm looking for something that can taught me:

1. Unit-testing (with some level of mocking)

2. Integration-testing (testing various components without hitting the UI but all the way up to the sending request, kind of like driving the front-end code without the UI).

3. Best practices/patterns for architecting large-scale SPA (hint: generic EventBus tend to be abused).

View on HN

We have a mid-size scale SPA and its suffering because of bloat. Functions are 2-500 lines long as an example. we've had critical bugs in the last 2 weeks and I got fed up and decided to start learning unit testing. Its been absolutely painful to get everything setup and started (Visual Studio). Nothing works. I would love to see a well written project to base my tests off of.

I would really love to see a well written SPA with testing, but I fear its almost reaching unicorn status. Most projects suffer from deadlines so they'll just never be written the way they should be and instead, the flow is now: patch it and move on.

That's not quite correct.

I've had good success in architecting/designing classical web-app (MVC-ish as overall architecture and minimum JS on front-end).

I can write unit-test with mocking and integration-test with in-memory database as part of my build/compile loop.

But I struggled a lot with front-end.

Ah yeah, we're having lots of issues with front end bugs causing crashes.

Front-end bugs causing crashes of... the back-end? That's a back-end bug.

I tried doing unit testing on our SPA codebase (200 k lines JS) for a while, but found it to not be worth the effort. UI is better tested through integration tests. We use selenium instead of jasmine these days. We have a ton of unit tests in the server code though, because it makes more sense there.

I think the right approach is to build from the ground up for testability both on unit-test and integration-test.

But one has to be very careful how to structure the pieces/components.

For example:

Do not write extensive unit-test on the UI but definitely have extensive Selenium tests for the UI _library_ (if you are a library builder). If you are a library user, assume the UI works as advertised and attaching/removing event-listener can be considered "configuration" type of code: test it once to see if it is configured properly and that's it!

If the SPA uses some sort of MVC/MVP, I'm hoping I can:

1. For unit-test

- unit-test individual M,V,C,P, Service, Helper, Model Validators, etc

- ability to mock different aspects

2. For integration-test

- ability to construct the whole thing (MVC/P) including the back-end, mock the View, and start controlling/simulating the code execution from the Controller/Presenter

The integration test can cover more than the unit-test to the point almost close to Selenium type of test but not as brittle as Selenium.

Reply on news.ycombinator.com