3 ms·

If it really E2E from user perspective you shouldn't doing any magic and manipulate POST data.

• danShumway 7y ago
  You're not technically wrong, but unit/integration/E2E are not hard categories for tests, they're just points along a continuum. Sometimes I want to directly control a browser to run a test or examine a UI component, but I still want to mock parts of my application. This is one of the biggest weaknesses with Selenium -- it takes a very narrow view of what testing is, so it becomes much less useful as soon as you're trying to do anything interesting. Different applications call for different testing strategies. Selenium could be a low-level browser controller that allows you to write strict E2E tests, but instead it's a low-level browser controller that is almost fanatical about only supporting strict E2E tests, even when it means that basic actions need to be more complicated. I think that's a design mistake, but whatever.
  • Qerub 7y ago
    > Sometimes I want to directly control a browser to run a test or examine a UI component, but I still want to mock parts of my application. If you're building a SPA, you can mock out the backend and control the backend mock behaviour in your Selenium test.
    • danShumway 7y ago
      It's not that Selenium makes it impossible to do things like this, it's that it makes it arbitrarily harder. If you want to do something like request interception, you have to point your front-end at a proxy server and mock things there. If you want to test a file upload, you have to simulate typing into the dialog and then use a literal file on the disk. It's just pointless friction for most testing setups. It's not that E2E testing is bad, it's that in some projects there's room for a Selenium-style tool across the entire spectrum from E2E testing to unit testing; particularly if I'm testing something like D3 code, or parts of a CSS layout. It's all doable, it's just that Selenium makes it all needlessly difficult, because its point-of-view is that your front-end should be treated mostly like a black box, and that any mocking that does exist should be happening via endpoints and application connectors. I like Selenium -- I prefer using an Open protocol over Puppeteer. I just feel like that protocol could use a lot more design work.
  • bluntfang 7y ago
    >This is one of the biggest weaknesses with Selenium -- it takes a very narrow view of what testing is Selenium/WebDriver isn't a testing tool. It's a a W3C protocol for remote control of web browsers. I think once you get over that misconception, selenium starts to make a lot more sense.
    • danShumway 7y ago
      That still doesn't explain to me design decisions like how WebDriver's file upload works. If I'm remote-controlling a browser over a network, wouldn't I occasionally want to send it an arbitrary file upload? Why do I need to separately transfer the file using a different service, and then refer to it with the disk path? The only reason I can think of is, "normal users couldn't do that." But normal users also can't control a browser over a network. There's no reason to restrict a control protocol to only things that normal users can do.
      • bluntfang 7y ago
        >There's no reason to restrict a control protocol to only things that normal users can do. The selenium maintainers seem to have a very strong opposite opinion.
    • shawnz 7y ago
      That is just further reason why it ought to support scenarios that the grandparent was describing, like modifying request data, even if that functionality is not useful for automated testing
• deleted 7y ago
  [deleted]