Test Suite borked

[Mirv]

From other comments ...

We are basically trying to get to the point where we can start making changes & be sure we don't break things elsewhere ... test drive development style not required but it's what I'll be doing once we get the test suite caught up.

Brute force removal of files reveals the fixtures in at least 2 files are killing all entrees...haven't isolated which ones. This is somehow related to the comment system from disqus. I'm working on it, but might just regenerate the entire test/ folder & then paste back in your tests.

On the comments ... The long story is we will have to test those disquis comments with stubs in our program & then there will be an integration test to ensure the words we enter on the comment are being saved & served back to use by disquis.

We absolutely have to do this as I spent 7 hours chasing back & forth between the user_id & chef_id, then some more on the current_user versus set_user. This is before we even get into the more complicated controllers you have.

I'll start that work when I know where we stand on your repo system with your other work. @jatwell93

[jatwell93]

i can definitely see how TDD is so important, because i feel like everytime i fix something i break something else at the moment.

Just wondering whats the best way for me to use github with this project, as i dont want to stuff up any of your work. Should i use a new branch everytime i work on a change? then merge them over if it works?

Thanks again for all your help on this project! i was almost at the point of giving up but now i have my enthusiasm back for it

@Mirv

[Mirv]

I'm trying to use one branch per controller fixed right now. Then pull request. At first I was using your c9 ide. I'd say the branch & merge gives us a good handle on how to pull back or compare anything bad.

Everytime I work on master, I regret it.

My only observation is the merges get really huge if not done every day or other day & it gets tough to decide whats needed. I try to push the branch to repo every time I log off. Then if someone is paying attention they can flick their the branches & see if there's new work being done.

We could extend that by linking to the work (commit url or hexi code) in a comment on the issues it addresses - that way I basically get a notification every time you update anything in the project & I can avoid that area or give suggestions too.

[jatwell93]

alright thanks for that i'll stop using the master branch now and make sure i check all your commits before starting to code. is this the correct process for pushing commits from a branch
git checkout -b [name_of_your_new_branch]
git status
git add .
git commit -m "done finishing x"
git push [name_of_your_new_branch]

[Mirv]

So this process is called "workflow" ...

• git checkout [branch we will be copying]
• git pull origin [branch we will be copying] This grabs the branch from the github repository. Change the name to w/e branch working with. Alternatively, there's a way to pull the changes check if you like them & then accept them - Link
• git checkout -b [name_of_your_new_branch] The name should be something related to what you're fixing like controller/view/model name or controller#action & toss the date on there in this format MMDDYY (month/day/year) - so we know at a glance (without clicking around when it's from)
• git add . This adds the directory...if you edit in the controllers & the view directory you're missing stuff, this might be why I had tons of issues getting your app to run initially...chunks of it missing randomly. Technically, to avoid including things you don't want there are better ways. See bottom of this message.
• git commit -m "done finishing x" It's helpful to list why you are changing things in summary, as if someone is curious we can always see what you changed with a few clicks.
• git push
• git checkout [branch we originally started on]
• git merge [name_of_your_new_branch]

---

Use of git add . ... just adds a directory, meaning you'll likely miss something in other directories.

If you're feeling really lazy use git add -A which will do the whole project, minus the gitignore file.

Best practices say you should be using git status to see what files you changed, then git add [name_of_file] to control whats going to the git repository. If the path is long, I usually just highlight it from the git status list & then copy/paste it with control+c/control+v since c9's rightclick copy seems to have issues.

[jatwell93]

Thanks for that @Mirv Mirv, i'll 100% be following that to the letter from now on.

[jatwell93]

After the git merge is done on the master does that branch disappear? i.e i create a branch following your steps the merge it back to the master then push up the commits can i go back to that branch to keep working without generating any problems?

[Mirv]

1. No, it won't disappear, some people delete them after a period of time. Deleting a branch needs git branch -d [nameOfBranch]
2. You don't want to handle it like that...I might be misunderstanding what you're saying but it sounds like you are doing a variation of "good working master" & "test branch" type thing. What you want is "good working master" + "branch: feature to add likes/dislikes" + "branch: fixing devise_for (logouts)" + "branch: mirv is doing teste suite".

To rephrase all of that simply, after you merge that branch - you are done using it.

There's a bunch of reasons for this, but the jist of it is the master is the nexus (centerpoint) where all fixes & features meet, branching off master is always preferred.

(the reason I kept working off recipeVersion2 before was that I wasn't a full contributor on the project & couldn't merge to master).

[jatwell93]

Awesome thats what i thought one branch one problem/feature then done.

[Mirv]

one branch one problem/feature then done.

Basically yes, but they don't count master as a branch

[Mirv]

Test suite runs now as of #30, individual errors & failures can still happen, but the code doesn't crash immediately regardless of test