stevenhaddox / SUPPORT

SUPPORT: Setting Up & Provisioning Pragmatic OSS Ruby Technologies
MIT License
3 stars 1 forks source link

Migrate Server, ServerUser, and User specs to be vagrant independent #5

Open stevenhaddox opened 11 years ago

stevenhaddox commented 11 years ago

As a developer I should be able to run the test suite independent of having a server such that the test suite remains fast and isolated.

Acceptance criteria:

kchien commented 11 years ago

I finally installed Vagrant. Once I get the specs passing that depend on Vagrant, I'll refactor to Cukes and start introducing mocks.

stevenhaddox commented 11 years ago

@kchien I'm not sure there's any benefit in migrating these specs to cuke unless you want to test them via aruba perhaps? I'm not sure they need to be quite that BDD yet as the only CLI for these thus far is the two or three rake tasks that exist currently. We can certainly discuss this week if you want to meet up and once you see what's currently there ;)

kchien commented 11 years ago

@stevenhaddox Now that there are clear instructions on how to set up your environment prior to running tests, I think I have an idea on how to reduce -- if not eliminate for the time being -- touching the file system. Have you looked at, or considered, the fakefs gem?

stevenhaddox commented 11 years ago

@kchien I haven't, but I've heard of it and am more than open to using it if you want to take a stab. Are you thinking FakeFS would be appropriate for the entire remote server setup & chef deploys or more so just for the config file / local pubkey type stuff?

kchien commented 11 years ago

@stevenhaddox I'm thinking the latter, so that we play nice and not touch the users files. Do you think that will work? Are there any other files being read in while the tests are running that I'm not aware of?

stevenhaddox commented 11 years ago

@kchien sorry for the delay on this reply. I think the latter is probably more appropriate too. I still plan on keeping the example file there obviously, but I'm fine with moving the example file to the test suite via FakeFS if that works (it just means we'll have to maintain both the FakeFS testing version and the example file versions if we make changes to the file structure).

The support.toml.example file is definitely the only file being used in the tool currently.