[deleted]
100,000 e2e selenium tests? Sounds like a nightmare
11–20 of 58 posts
Re: 100,000 e2e selenium tests? Sounds like a nightmare
#12> I would definitely choose a comprehensive suite of automated unit tests over a comprehensive suite of end-to-end/system tests any day of the week. Huh, after working on very large applications with tens of thousands of unit tests I'd choose the opposite. I've found little value from unit tests. They're sometimes good enough for catching the lowest common errors. With very complex applications that involve a great d…
>I've found little value from unit tests.
Not even when re-factoring? Refactoring code without unit tests makes me extremely anxious and I try to avoid it.
Re: 100,000 e2e selenium tests? Sounds like a nightmare
#13I spent a year doing this for a Fortune 500. When you have a fractured back end there is no other option. Here is a talk I gave to our local Ruby users group. Code works out of the box on Nitrus.io, https://github.com/chadbrewbaker/LiterateFunctionalExplorati...
1) Use the page object model. http://martinfowler.com/bliki/PageObject.html
2) Think about your functional tests like tours through a city. http://ptgmedia.pearsoncmg.com/images/9780321803023/samplepa...
3) As your tests become more advanced abstract them locally to two simple questions. What page object did I come from, and what action did I do on that page to get to this page?
Re: 100,000 e2e selenium tests? Sounds like a nightmare
#14> I would definitely choose a comprehensive suite of automated unit tests over a comprehensive suite of end-to-end/system tests any day of the week. Huh, after working on very large applications with tens of thousands of unit tests I'd choose the opposite. I've found little value from unit tests. They're sometimes good enough for catching the lowest common errors. With very complex applications that involve a great d…
>I've found little value from unit tests. Not even when re-factoring? Refactoring code without unit tests makes me extremely anxious and I try to avoid it.
Yeah it all depends; unit tests can make refactoring even more difficult (especially if you heavily rely on mocking).
I've done major refactoring (moving from one language to another) and the testing was done entirely on the rest api. With several thousand tests I felt very confident that the user experience and expected behavior remain unchanged.
Honestly I don't hate unit testing and do I use it on a regular basis, the article was rather heavy handed.
Re: 100,000 e2e selenium tests? Sounds like a nightmare
#15> I would definitely choose a comprehensive suite of automated unit tests over a comprehensive suite of end-to-end/system tests any day of the week. Huh, after working on very large applications with tens of thousands of unit tests I'd choose the opposite. I've found little value from unit tests. They're sometimes good enough for catching the lowest common errors. With very complex applications that involve a great d…
No-one ever said that integration tests and unit tests are mutually exclusive. Integration test the happy paths, small integration suite that proves everything works together. Unit test the individual units of functionality or behavior, whichever you're more comfortable with. Unit tests aren't supposed to tell you that the whole system works. Unit tests exist for two main reasons: Confidence that you can refactor you…
The problem is that refactoring definitely can also cause components to not do what they're supposed to do outside the happy path.
Re: 100,000 e2e selenium tests? Sounds like a nightmare
#16From my experience, we don't need to discuss if we should use unit tests, or integration tests. We just actually need to write tests. They are often left to last, never completed or poor. If you have an exhaustive set of either, good for you!
Re: 100,000 e2e selenium tests? Sounds like a nightmare
#17Earlier quoted context omitted.
No-one ever said that integration tests and unit tests are mutually exclusive. Integration test the happy paths, small integration suite that proves everything works together. Unit test the individual units of functionality or behavior, whichever you're more comfortable with. Unit tests aren't supposed to tell you that the whole system works. Unit tests exist for two main reasons: Confidence that you can refactor you…
The problem is that refactoring definitely can also cause components to not do what they're supposed to do outside the happy path.
Then you're not refactoring. Refactoring is defined as changing how the code is implemented without affecting the functionality / behavior of said code.
Also, Unit tests are where you ensure the non-happy-paths are functional (error handling, input robustness, etc).
Re: 100,000 e2e selenium tests? Sounds like a nightmare
#18> I would definitely choose a comprehensive suite of automated unit tests over a comprehensive suite of end-to-end/system tests any day of the week. Huh, after working on very large applications with tens of thousands of unit tests I'd choose the opposite. I've found little value from unit tests. They're sometimes good enough for catching the lowest common errors. With very complex applications that involve a great d…
I think it depends how tightly your business logic and your view are bound and how well your business logic is abstracted. I use Angular at work and 90% of the bugs we get can be caught by a unit test. On a rare occasion something will be mis-labeled on the markup and the two-way-binding "fails" silently, but usually our bugs are errors in the logic. Whenever you fix a bug in your code, try to cover it with a unit te…
Also it's much less tedious when developing a web app to test your code using unit tests, rather than doing curl commands and/or actually launching the frontend to test the API manually and trying to glean errors from the web inspector.
Re: 100,000 e2e selenium tests? Sounds like a nightmare
#19> I would definitely choose a comprehensive suite of automated unit tests over a comprehensive suite of end-to-end/system tests any day of the week. Huh, after working on very large applications with tens of thousands of unit tests I'd choose the opposite. I've found little value from unit tests. They're sometimes good enough for catching the lowest common errors. With very complex applications that involve a great d…
Does deleting products ever break? I wouldn't bother with any tests, unit or functional, for a code path that doesn't have any logic in it - if it compiled then it's almost certainly correct.
Where testing is useful is when there's complex logic. And such logic is much easier to test at the unit level.
Re: 100,000 e2e selenium tests? Sounds like a nightmare
#20> I would definitely choose a comprehensive suite of automated unit tests over a comprehensive suite of end-to-end/system tests any day of the week. Huh, after working on very large applications with tens of thousands of unit tests I'd choose the opposite. I've found little value from unit tests. They're sometimes good enough for catching the lowest common errors. With very complex applications that involve a great d…
Does deleting products ever break? I wouldn't bother with any tests, unit or functional, for a code path that doesn't have any logic in it - if it compiled then it's almost certainly correct. Where testing is useful is when there's complex logic. And such logic is much easier to test at the unit level.
I can imagine deleting products may be failing due to some UI change. Maybe a button isn't visible in certain IE versions. Maybe the JS code executing the backend request is failing in some browsers. That's where e2e tests are useful.