start of update tests

[mbfrahry]

Signed-off-by: mbfrahry [email protected]

[mbfrahry]

@wenlock This branch is good to be merged. This just switches all the current tests to use the new framework of calling a specific chunk of data instead of it just using dev

[sfc-gh-eraigosa]

thanks @mbfrahry but did you notice your sign-off is coming from your vagrant user account?
Signed-off-by: vagrant [email protected]

Will try this out, any chance you can fix the sign off?

[sfc-gh-eraigosa]

Trying to understand why we want this. Could you explain the challenge your facing with not letting environment represent a default globally for all test here and what use case we're solving by allowing every test case to define their own default environment value? My thoughts on environment was that we could add progressively complex testing for things like a test and production environment in the future, but in this scenario, I'm thinking we might just be moving a default that should be located here to all other test case calls.... wanted to get your take on this.

[mbfrahry]

So at the time, it seemed like this was server_profile test specific. So when I was adding new tests I added tests specific to other things. It keeps the test chunks small and specific to the tests we are running. I might have misunderstood this though. My test data looks like

{
  "name": "dev"
  //initial test data
},
{
  "name": "test_ethernet_network",
  // data for ethernet
}
.
.
.

[sfc-gh-eraigosa]

OK, that makes sense... so instead of environments, we are really saying we can purpose this as a way to select test specific to a particular unit case where we can start separating.... I think your way might actually be cleaner, it's to bad go doesn't support defaults. Then we wouldn't need to pass arguments like "dev" every time. OK, I'll accept that as a good way to go +1.

I'm going to merge my other PR for the make process, this should allow you to rebase and try this build again.

[mbfrahry]

Perfect!

[sfc-gh-eraigosa]

@mbfrahry i also had problems building this project on my desktop this morning, so I opened issue #61

I'll open a pull request shortly to help with fixing that, hopefully it helps you test these changes locally as well.

[sfc-gh-eraigosa]

@mbfrahry checkout pull #62 , This should address the issues with building locally.

Also, if we probably need to merge this one ahead of the change your working on here because it forced us to change the environment settings for travis ci so that USE_CONTAINER=false, and remove GH_REPO, GH_USER values. Once we merge #62 then we'll have to rebase this change, but I'm hoping you can answer my other questions on this review.

[mbfrahry]

@wenlock Looking at all the comments.

[mbfrahry]

I'm good to merge #62 if you are

[sfc-gh-eraigosa]

why remove the build status?

[mbfrahry]

Oops, I was just trying to fix the signature without making drastic changes. I pulled this out of my readme so I wouldn't be getting builds passing or failing from your repo onto mine. I'll fix this.

[mbfrahry]

Fixed