3 ms·

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 programm

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).

bonesinger 11y ago
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.
- edwinnathaniel 11y ago
  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.
  - bonesinger 11y ago
    Ah yeah, we're having lots of issues with front end bugs causing crashes.
    - davelnewton 11y ago
      Front-end bugs causing crashes of... the back-end? That's a back-end bug.
Joeri 11y ago
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.
- edwinnathaniel 11y ago
  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.

bonesinger 11y ago

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.

edwinnathaniel 11y ago
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.
- bonesinger 11y ago
  Ah yeah, we're having lots of issues with front end bugs causing crashes.
  - davelnewton 11y ago
    Front-end bugs causing crashes of... the back-end? That's a back-end bug.

Joeri 11y ago

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.

edwinnathaniel 11y ago
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.