Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
IMO, "load testing" clarifies the intent well enough. You could look at Amazon Web services, people discuss using EC2 to generate multiple "users" hitting your site - but you'd need an external testing site for that.
+1 for OP having a good idea of the basics - I was trying to figure out from glowcoder's questions and answers if (s)he was already an SDET or a really savvy dev.
I think the only reasons to mention company names are (a) the company name is recognizable (b) the info is positive (c) the use of the company name adds credibility, e.g., "This is how Fog Creek does things" or "Google does that" or "Microsoft and Amazon do this differently, but both approaches seem to work OK". I mention my previous experiences at MS by name when appropriate and positive, but not my current (small and unrecognized) employer.
But . . . I usually didn't test the code before creating them. It's pretty rare that the code was finished before I made my tests. I thought that parallel development of tests and code was standard?
I wanted to add . . . a well-designed fixture can be used for both mock and E2E tests; just make the API service configurable, so you can point it at either your mock service or the real one. This also allows you to test for possible changes to Twitter's API, e.g., what if that method that currently never returns null now does someday? You can't test that with a real API call! @glowcoder, sorry for referencing you in the last comment, I misread your comment :)
@Traroth, @glocoder, there is definitely a difference in philosophy between mock testing and standard testing. This article touches on it: stephenwalther.com/blog/archive/2008/06/12/… I like to mix the philosophies: I verify that the API is called correctly in the mocked tests (the majority of my tests), which generate fast tests that can often be run on build and are more useful. I verify that the API does what I expect in E2E tests, which are fewer in number and slower - but I'm covering less surface area, because I covered the rest in my mocked tests.
