The self initializing fake sounds like a pretty good idea. The unit tests would still be vulnerable to a signature change though, with the replay data being old, but this would at least let me easily regenerate the data if I am concerned that something may have changed, and it would be far better than trying to manually re-code all the mocks involved. Is there a library that you would recommend for doing the recording/playback for a node application?
On Monday, May 26, 2014 11:02:47 AM UTC-5, Daniel R. wrote: > > I also tend to write more automated integration or system tests since I > find more issues in the flow of data between various parts of the > application than in individual modules. Fowler mentions a technique about a > mock that records the results from the real service ( > http://martinfowler.com/bliki/SelfInitializingFake.html) that can then > speed up future tests runs. Outside of unit tests you can replay the saved > function calls and ensure you get the same results. > > -- Daniel R. <[email protected] <javascript:>> [http://danielr.neophi.com/ > ] > > > On Sat, May 24, 2014 at 9:40 PM, Jake <[email protected] <javascript:>>wrote: > >> Thanks Bruno! A followup question regarding the unit testing: I like to >> write lots of unit tests and I like knowing that when another developer >> changes code that might break something elsewhere in the codebase, a unit >> test will fail to let them know this happened. Coming from a >> statically-typed language background, I am accustomed to using mocks to >> isolate what I'm trying to test, where if something like a function >> signature were to change, the test would fail to compile, but in JS (or any >> other dynamically typed language) the tests continue to pass just fine, >> since the mock data continues to work just fine. It seems like a change in >> my testing strategy is needed. The obvious solution seems to be to write a >> lot more integration tests, possibly sometimes in place of unit tests with >> mocks. Do you find yourself more often writing a very large number of >> integration tests and avoiding unit tests with mocks? >> >> >> >> >> On Saturday, May 24, 2014 2:13:01 PM UTC-5, Bruno Fuster wrote: >> >>> The same rules that you follow for other languages, mainly dynamic ones >>> like ruby python groovy. >>> >>> - separation of concerns >>> - well structured and small methods, using either OO or a functional >>> style >>> - a lot of testing, unit, integration, etc >>> - pair programming >>> - learn to not make callback hell, using small functions, async or >>> promises, and take advantage of functions as first class citizens >>> - the better you plan and design with your team, the less refactors you >>> might need >>> >>> Cheers >>> >>> On May 24, 2014, at 5:55 AM, Jake <[email protected]> wrote: >>> >>> In discussions at my company about adopting node.js one concern that >>> tends to come up is about managing the codebase of a large project where >>> about 10 developers are working on it concurrently. >>> >>> >>> I would like to get some suggestions, techniques, best practices, and >>> advice from the group here for: >>> >>> >>> 1. maintaining a clean codebase for a large node.js web application >>> >>> 2. refactoring in a large node.js project (probably tied to #1) >>> >>> 3. having a team of about 10 developers working on the same node.js >>> application >>> >>> 4. quickly ramping up new developers (that already know JS well) on a >>> large node.js application >>> >>> Thanks in advance for your advice and recommendations! >>> >>> -- >>> Job board: http://jobs.nodejs.org/ >>> New group rules: https://gist.github.com/othiym23/9886289#file- >>> moderation-policy-md >>> Old group rules: https://github.com/joyent/node/wiki/Mailing-List- >>> Posting-Guidelines >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "nodejs" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/nodejs/182298cb-ff3a-4a9d-a76f-b25be5a9e657%40googlegroups.com<https://groups.google.com/d/msgid/nodejs/182298cb-ff3a-4a9d-a76f-b25be5a9e657%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >> Job board: http://jobs.nodejs.org/ >> New group rules: >> https://gist.github.com/othiym23/9886289#file-moderation-policy-md >> Old group rules: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> --- >> You received this message because you are subscribed to the Google Groups >> "nodejs" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/nodejs/c7aacfca-91d6-44c9-8d65-531d74341cf4%40googlegroups.com<https://groups.google.com/d/msgid/nodejs/c7aacfca-91d6-44c9-8d65-531d74341cf4%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/cc76736b-48b1-48a2-b2e9-68b5f9ed9933%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
