On Feb 26, 2014 4:01 PM, "Jim Porter" <[email protected]> wrote: > If you don't have tests, but the patch should have tests, set in-testsuite to "?" and file a followup to track landing the tests. When they land, set in-testsuite to "+" for both bugs.
This should be very rare though. The only time when it is ok to land a patch without tests is if it's for a critical blocker, we are close to deadline, and if you've thoroughly tested the patch manually. And then too should you work on tests as a followup quickly after. It is not ok to land a big new feature right before feature freeze without tests. A new featre isn't done until it has tests, and so of it doesn't have tests before freeze date then we should simply let it wait until next release. We do releases very often so slipping a featre by one release should generally not be a big deal. It is better that we take the time and do things properly, with tests, in the next release than that we rush things in this release. This also means that people should take test writing time into account when planning. I.e.don't just budget for the time it takes to write the code. Also take into account that you'll need to spend tike on tests. The goal is absolutely not to have people work nights and weekends just to have time writing tests too. And tests shouldn't just cover the base cases. The more important thing to cover is actually edge cases and things like timing issues. Those are more likely to be the ones to regress anyway. There are also situations where writing a test for something is excessively hard. In these cases please try to work with others on seeing if we can make improvement to testing infrastructure or even add new types of test suites which would enable testing the patch more easily. The only way we will get better test coverage is if we invest in testing infrastructure and make it fit our needs. However in situations like this I think it can also be ok to mark a bug as 'in-testsuite:?' And look into testing after the patch has landed. But please remember that our codebase is changing rapidly. The only way to ensure that something you fixed or wrote won't break again is to add a test. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
