Ask HN: At which level should one implement TDD in a web app? Is writing browser automation test enough (Eg: Assert that a page has these inputs and a button. Before the button is clicked, there are 0 records in DB table. After clicking the button, there is 1 record.), or do we want to write tests in levels below as well (Eg: After writing browser automation tests, write feature tests, and then write unit tests.)? |
In practice though, what you want is sufficient coverage of your business logic. If you are well versed in TDD, your code architecture will be sufficiently decoupled even if you don't do TDD per se, so you should be able to test whatever is important for your application.
However, note that testing each layer independently generally gives you the best bang for the bug: trust that you can update code without worrying about breaking something. Then you only need minimal integration tests to ensure integration points are not broken.
What you describe sound like full system tests which are slowest, and you should have only a few of them in comparison, basically to replace manual QA.
Note that everybody uses slightly different definitions for which tests are which, but I hope you get the point.
If you want something maintainable in the long run (5-10 years), it's probably not the best idea to start with that approach. But then again, you probably have no idea what direction you should be heading for the next 5-10 years, so it's not a big deal.
I know it's a bit conflicting advice, but that's the point. When you know exactly what you are building (which is seldom the case with web apps), you want to do it right from the get go. When you don't really know, it does not matter since a few years down the line, if successful as a product, you'll be refactoring heavily and probably doing it the right way at that point (iow, full tests come last).
Browser automation tests are horrifically expensive. Unit tests are cheap if (1) you don’t let them get expensive (yesterday I wrote tests a process that needed key pairs, I genned keys once and hard coded them) and (2) the design is appropriate.
One design might be untestable. Another design might sacrifice design for flexibility. There is another design which is testable and good in other respects.
The worst cost of tests is that they take a long time to run.
Also, even if I write feature or unit tests to invoke some class methods, there's no guarantee that they'd be executed when a user performs some action in the page. To do that, I'd either have to manually check it (Bad, because its not repeatable.), or write browser tests anyway.
Edit: Typo
If the framework is correct in design and implementation then you can change something superficial and the odds are good that the change is superficial and it works.
If you are starting from the outside and working in it might seem easy to get started but you will fall behind in productivity compared to people who do the opposite.
I have frequently worked with testers and frequently those testers have chosen to automate their work and I am all for that; a dev doing the same might catch some errors that way but they may also encode conceptual mistakes.
It’s best to find the simplest set of tests and test methodologies that give reasonable coverage.
https://www.amazon.com/Quality-Free-Art-Making-Certain/dp/04...