On Thu, Sep 25, 2014 at 12:50 AM, Paul Julius <[email protected]> wrote:
> Hi Michael, > > Thanks for the response. Some excellent points. I'll respond to a couple. > > > As such, I strongly favor integration tests run against stage > environments to make sure > > things work, and coupling that in a rolling update against a production > environment as > > a condition to decide whether to add something back to a load balanced > environment > > there as well - ideally using the same tests, but that's not always > possible. > > Agreed! Me too. I didn't address the downstream deployment stages, but > this would be consistent with my approach. > > > > While more of a unit test thing, I personally find Cucumber to be wasted > effort because > > most product-management types (I guess I qualify) are not going to be > the ones writing > > test stubs, so it's usually fine to just go straight to tests. > > Understood. On the contrary, I have found the type of tests I write > when using a natural language approach to be a great mechanism for > communicating requirements within a team. Though I wasn't sure, it > read like you are thinking of Cucumber as a unit testing framework. I > never think of Cucumber as a "unit" testing framework. > I guess what I'm trying to say is it's a language of defining "these are my tests", "someone go implement these". I would agree it's not specifically unit test driven, but I guess it's more of the statement that it doesn't provide a lot of value to me over well named functions and comments in the test file. Stubbed out test functions would do the same thing. A lot of users in ops land are new to development testing systems, so I want to make it clear this isn't required, and there's not a big gap that says you must incorporate 4 or 5 extra tools to use something as basic as Ansible in most cases. That's the important thing I'm trying to combat - the feeling that it's *not easy* and you need all this extra stuff. For those people that like it, great - I don't want them to stop doing that if that works for them for sure. > > In any case, my point isn't about Cucumber in general, but rather > about the good practice of creating an acceptance test for a body of > work about to be embarked upon. I am glad for teams to use whatever > tool they think makes the most sense for their combination of team > members and customers. By acceptance test, I simply mean an automated > verification that the features we want actually do exist in the system > that a customer and engineer can collaborate on. > > > > Good integration tests for ops are more important -- is this web service > responsive? > > Agreed. > > > Not things like "is the file permission of this file the same thing it > is listed in the configuration > > system - as that just duplicates configuration in two places. > > Duplication is precisely the point, sort of. I like Uncle Bob's point > about unit testing being the double entry accounting of software > engineering. We express the functionality we want in two ways: code > and test. Then we automatically make sure our column sum equals our > row sum. > This part I strongly disagree with. When configuration exists in two places, the maintaince costs double. A colleague raised a very good point WRT ServerSpec in that in many cases Puppet needs double checking more because it can fail and only partially evaluate a DAG, but Ansible will fail-first and make you fix a problem before proceeding. If it can't chmod something to a value, it will yell at you, and so forth. The checks you insert using get_url and wait_for and assert/stat, etc, can be part of the main playbook. Again the point is - don't make Ansible harder than it needs to be, a lot of the purpose of it is to allow you to quickly move on to other tasks. One of the pitfalls of "infrastructure is code" is it brought software development levels of complexity with it to infrastructure, when it should have brought only the idea of source control. This is what we're trying to change here :) Hope that makes sense! -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwaYmFdVBjdNucOStSBO6ornzzcAAy6FEdj%2BxgTDLqQsA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
