Hi, On 2014-11-11 03:13, David Lang wrote: > you still need those credentials for your sandbox, right? > > If MySQL isn't installed on the system you will need to install the package > (requiring root + distro specific knowledge), if it is installed, you need to > configure users and permissions for the test user (requiring DB root > equivalent > + distro specific knowlege)
Yes, running tests against any third-party application would require access to those applications while testing. Theses tests are called "integration tests". Because you should *not* depend on those third-party applications you often cannot run your integration tests every time you run the normal test suite. Therefore you would split your tests. And this is already done for rsyslog: The mysql tests for example are separated. But this doesn't mean you cannot test the ommysql at all without mysql: You can write a mock so you can test your code at least. BTW: Travis will allow us to test against a running mysql each time... >>> But let me be clear. From this thread, it looks like these should be our >>> project priorities: >>> >>> 1. make the testbench fully automatic and self-contained >>> 2. create unit tests >>> 3. create more and better integration tests >>> 4. document >>> 5. fix bugs >>> 6. develop new features >>> >>> [...] >> >> [...] >> >> Yes, I am voting for changing the priority order like you said. > > I disagree that 1, 2, and 3 are more important than 4 and 5 (where 6 lives is > subject to a lot of debate) Wait, this order is not set in stone. For example, to write tests, you have to know what a component should do and how it should be used. So you need a documentation before you can write tests. > you could completely halt all documentation, bugfixing, and new features for > a > year while creating tests to cover everything. > > Testing is useful, but the end purpose of the software is not to pass tests, > but > rather to provide capabilities to the user. > > As an extreme example, I know of a company that lost a month of development > and > missed having the product ready for a national trade show because they got so > caught up in writing tests for everything that a test that didn't work right > when the software was being shutdown (after which it would be reset for the > next > test) HAD to be written before anything more could be done, and there was an > upstream bug in one component that caused this exit to never work cleanly. > Don't > fall into a similar trap. Our views are not so far apart. To be clear: I don't want to establish a process above the product. But the process should be part of the product. Change the way you currently work: When developing a new feature, start with the documentation. If you know how your new feature should look like, should be used, start writing tests so you can be sure your new feature is actual doing what you are are expecting. Now you can start the actual coding... In the end you have a new feature, fully documented and tested. If you don't follow this work flow, you will end up with the current situation: You maybe have great features -- but nobody knows due to missing/hard to use documentation. The tests will help you to keep your hard work working. Imagine you spend days for a new feature but another change will break it. Without tests you will only notice if somebody will actual try to use your feature and fill a bug. But we all know that this don't happen that often. Also, if you start looking for a new product which maybe solve your problem you are currently facing and experience a bug which is a show stopper for you in this moment, you will skip this product. So if Rainer should decide to switch the work flow like described, this would only help new features. But we still have to deal with the past. That's why I recommend to change priority for a moment. Like a "sprint"... like a bug hunt day/week/month where everybody focus on squashing bugs. If there is an upcoming "national trade show" where you want to show something new, yes... do that (but please follow the new work flow). But I am not aware of something like that in the next 4 months and I am not aware of a missing feature which must be implemented ASAP or rsyslog will go away... -Thomas _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
