221–230 of 338 posts
Does anyone have any good resources on writing front-end integration tests? I've had nothing but terrible experiences with selenium. And I recently tried Nightmare (which is Electron-based), but it wasn't much better.
Does anyone have any good resources on writing front-end integration tests? I've had nothing but terrible experiences with selenium. And I recently tried Nightmare (which is Electron-based), but it wasn't much better.
Don’t think “integration” — think “full stack” these will find configuration and connectivity bugs more than business logic bugs. These can’t be your only tests.
They need to run as part of your CD/CI pipeline automatically, otherwise, they won’t get run and will decay from disuse.
Headless browsers (HTMLUnit and PhantomJS) are easier to work with than “real” browsers. Haven’t used Chrome headless yet.
Front end bugs are often fiddly and visual. Screenshots + human review can be a cost effective supplement to manual testing, but can never replace it.
Good error logging and reporting is also key. If your front end tests break something, having the backend tell you what broke will save you time.
I tend to keep these “full stack” tests to happy path scenarios, as they are slower to write and to run than lower level integration tests.
Good luck.
Earlier quoted context omitted.
Not really. It makes you commit to an API upfront, this is the exact opposite of what exploratory programming should be (noncommittal, keep everything open).
No with TDD you don't need to go in with a structure in mind, the structures arise as you write more tests and get a proper understanding of what components you'll require. Red, green, refactor - each refactor brings you closer to the final design.
When I was a UX prototyper, none of my code ever made it into production.
Earlier quoted context omitted.
No offence, but you work in a bubble of sorts. In enterprise we are absolutely expected to run against a wall - preferably fast.
The bubble happens to be at the bottom of everything everyone runs. If we--or kernel folks for that matter--applied the advice of the article to our development practices, our system meltdown would be your system meltdown. Sure, you have requirements from management. So do architects and engineers for building bridges. Yet they still have a duty to build bridges that don't fall down.
Fortunately, integration-oriented projects have arisen more recently such as https://kernelci.org/ and https://github.com/os-autoinst/openQA/
Anyhow, it would make me a bit sad if the v8 team is writing unit tests tightly coupled to the implementation. I've messed around with the codebase and I didn't see tests like that - could you point to some?
Earlier quoted context omitted.
I totally agree with you on this one! The tone is absolutely immature and frankly disgusting. I would never hire a person with this kind of attitude, frankly because it is the ultimate creativity-killer in a team. This type of attitude is creating a culture where everyone is "to scared to learn" by being to scared to comment on things, or even to ask a simple question. So sad to see this...
Sorry for the harsh tone--probably an overreaction--but I think creativity is not the primary variable to optimize for in software development. I recognize that this opinion is a product of where I've gotten stuck in the software stack. However the OP's advice was basically "don't write tests because they slow you down." They even said that 100% code coverage was "a really bad idea". The OP's attitude was flippant, d…
Having said that, to be more OT. I agree with you regards the code coverage. However, the quality of Tests should be raised, as i would rather be in a position where people are aware that stuff can break and be on their toes, then to have false sense of confidence with 100% code coverage using poorly written tests (for example, tests so complex they need testing on their own).
And sometimes, it is more important to get an MVP out there, and collect the users feedback then the actual tests.
My point, its a dynamic world, and it doesn't hurt to listen to each other more!
Earlier quoted context omitted.
> What in the. serious. fuck. Of course tests test implementation details. Because _implementation details_ are where the goddamn bugs are. Testing is about testing inputs and outputs, not implementations details. Bad testing checks if you called this function or if you accessed this data. Good test checks that for a given input you get the expected output. > Please don't follow the advice of this. It's total crap. T…
If you have Google money and work on compilers, surely tests are more important than for say, a B2C app with lots of UI.
When people say “in the real world” they really mean, “in my insular world”
Why does everyone rethink a working strategy. Write lots of unit tests that are fast. Write a good amount of integration tests that are relatively fast. Write fewer system integration tests that are slower. The testing pyramid works. He even talks about it in this post, and then ignores the point of it. You write lots of unit tests because you can run them inline pre-commit or in a component build. If you integration…
The testing pyramid is built around a lot of assumptions which are often not true.
For example I run our ~10,000 integration tests in under two minutes on our large enterprise codebase. In recent years it has become possible to have fast integration tests.
I've worked on other apps that take 5+ minutes just to start up and integration tests can take hours.
Applying the same testing strategy to both does not make sense.
Integration testing is especially important when talking to a database. People seem to like mocking the data, but that completely misses the subtleties of how databases actually work, including aspects such as concurrency, transaction isolation levels, locking and such. There should be a few well crafted tests that modify the database from several parallel threads, and afterwards verify that no invariants have been b…
This is the part I don't get when people preach the gospel of ultra-isolated test suites where nothing talks to an external system. The most nontrivial parts of your code, the most likely to break, are those that talk to external systems. Building a mock of that system sophisticated enough to sufficiently capture even a significant fraction of the "real" failure modes is just as, if not more error-prone and daunting…
I know I have done it, and the application worked PERFECTLY until I hooked it up to a real database.
In this video, he talks of a concept called functional core, imperative shell. The functional core is your code that contains your core logic that can be easily unit tested because it just receives plain values from the outside world. The imperative shell is the outside world that talks to disks, databases, APIs, UIs, etc. and builds these values to be used in the core. I'll stop there—Gary's video will do 100x than I can do here :)
Behavior driven development (BDD) and test driven development (TDD) enable much faster coding when done well in my experience, and that includes full coverage fast unit tests, functional tests, benchmark tests, and integration tests. Unit tests are worth their weight in gold for quickly finding issues, both in our team's code and especially in cases of subtle changes among language releases, or unanticipated input ch…
Faster than what?