TDD-style developing

[shoes]

TDD-style developing

[PragTob]

Hi Ash,

I wrote that comment in the README just yesterday without real involvement in shoes4 before. I thought that that this was the spirit and I really like that spirit (being a relatively hardcore TDD person myself). I've to admit that it's hard especially if you're new to this sort of testing (like me) so my first pull request with some real code will most likely lack some tests which we can work out during the discussion.

Personally I'm all for revising the specs along with the new basic design. It's probably not the most enjoyable task but it has to be done, the sooner the better. If we work together we can get it going :-)

Just my 2 cents,
Tobi

[PragTob]

I'm currently working on your branch gtrying to get those tests passing, good exercise to familiarize myself with the architecture :-)

[pjfitzgibbons]

There are occasions where refactoring some core element ends up "breaking"
many other tests in the suite. I have found this to be a side-effect of
regression.
There are up-sides to the broken suite though. Re-think every test. Yes,
quite annoying by appearance, yet now I have a chance to reconsider how
this core change affected the rest of the code base... and I know exactly
every instance of the code base affected.
That last bit is HUGE, and is the whole reason for TDD. Think of
double-entry accounting. Yes, you write every transaction twice, in
different spots, yet if there is a mistake, or a budgeting change,
instantly it is clear how wide-spread is the effect.

I recommend making those core changes TDD style. I acknowledge that its a
BIG task. Maybe you could create a branch and push it up to the repo so
others can help? If you choose to take it on single-handedly (I'm not
saying take this option), we certainly commend your effort.

Shoes On
Peter Fitzgibbons
[phone]
Email: [email protected]
IM GTalk: peter.fitzgibbons
IM AOL: [email protected]

On Sat, Jun 9, 2012 at 3:15 AM, ashbb <
[email protected]

wrote:

I read the latest README. It says:

With all you do, please make sure to write specs as shoes4 is developped
TDD-style (see the Running Specs section above). So make sure that you
don't break any tests :-)

This statement is absolutely true. But for now, is it really economic?

The for now means that we have to revise/convert/reconsider basic
design, e.g. transition from modules to classes, window size, etc.

Try out this local commit.
The bin/swt-shoooes samples/simple-oval.rb woks fine. So, this commit
seems to be reasonable to convert App from module to class. But, in order
to pass all tests we already have, I have to update many other files.

This is because the tests are dependent on basic design.

So, what shall we do now?

• Do merge the commit if it breaks some tests.
• Temporarily, delete all codes and specs. Then add some codes and specs
  finished to revise.
• At first, revise all specs along with our new basic design.

---

Reply to this email directly or view it on GitHub:
#58

[PragTob]

For general progress you can refer to this pull request on ashbbs fork.

[wasnotrice]

@ashbb this is how I have been doing it:

1. Make the fix I'm working on. Commit.
2. Notice that it breaks a lot of tests.
3. Work through the broken tests, asking questions about the tests@pjfitzgibbons mentions (is this test still valuable? does it need to be rewritten because of my change? is the code too coupled, so that my change is affecting tests it shouldn't?)
4. Fix broken tests.
5. Fix broken code. Commit.
6. Fix broken tests.
7. Fix broken code. Commit.
8. More of this :)
9. When all of the tests are passing again, git rebase -i master and squash everything down into one commit
10. Push to master.

With this process, I can make small, broken commits as I go. But when I push my code, it is all working :)

This is also why I made Shoes.configuration.backend be parallel to Shoes.configuration.framework. It lets me change the architecture bit by bit, without breaking the rest of the specs.

+1 @pjfitzgibbons push big changes to a branch and ask for help :)

[pjfitzgibbons]

May I strongly STONGLY recommend that git-branch be used for this.
This is much safer than committing "temporary" changes to master and
rebasing.

Rebasing is evil, no matter where you read that it's OK. Rebasing really
needs to be reserved for very specific corner cases in merging and repo
admin.
I understand many disagree with the comment above.

Peter Fitzgibbons
[phone]
Email: [email protected]
IM GTalk: peter.fitzgibbons
IM AOL: [email protected]

On Sat, Jun 9, 2012 at 7:25 AM, Eric Watson <
[email protected]

wrote:

@ashbb this is how I have been doing it:

1. Make the fix I'm working on. Commit.
2. Notice that it breaks a lot of tests.
3. Work through the broken tests, asking questions about the
   tests@pjfitzgibbons mentions (is this test still valuable? does it need
   to be rewritten because of my change? is the code too coupled, so that my
   change is affecting tests it shouldn't?)
4. Fix broken tests.
5. Fix broken code. Commit.
6. Fix broken tests.
7. Fix broken code. Commit.
8. More of this :)
9. When all of the tests are passing again, git rebase -i master and
   squash everything down into one commit
10. Push to master.

With this process, I can make small, broken commits as I go. But when I
push my code, it is all working :)

This is also why I made Shoes.configuration.backend be parallel to
Shoes.configuration.framework. It lets me change the architecture bit by
bit, without breaking the rest of the specs.

+1 @pjfitzgibbons push big changes to a branch and ask for help :)

---

Reply to this email directly or view it on GitHub:
#58 (comment)

[wasnotrice]

Oh, forgot to mention, I do all that on a topic branch before merging back into master :)

[davorb]

The way I usually work is I have my tests, I change some things and then I run the tests again to see if I broke anything. That isn't really working too well right now, since the tests in master are broken.

Imho people should push the changes to a different branch until the tests pass.

[wasnotrice]

@davorb What tests are broken in master? Travisci says the build is green. I agree, master should be clean.

[wasnotrice]

@pjfitzgibbons I wouldn't say rebasing is evil, but it is unwise to rebase any commits that are public. For instance, once I push to a branch on my github fork, or issue a pull request, I wouldn't rebase those commits. But for local work it is very freeing to know you can commit things in an ugly state temporarily, and make it pretty again before pushing it.

[davorb]

@wasnotrice I just did a fresh checkout and it failed on Windows 7. Worked just fine yesterday.

https://gist.github.com/2903472

[ashbb]

@davorb Umm,... strange. I cloned shoes/shoes4 (commit af27147) and ran jruby --1.9 -S rake spec with --order rand:18712 option on my Windows 7. This is the log. No failures.

[PragTob]

@davorb @ashbb @wasnotrice green on my Linux machine as well

[PragTob]

Hm that's really weird, I checked your error log @davorb and the error that is causing most of the failures is the following:

[31mArgumentError:�[0m
       �[31mwrong number of arguments (2 for 0)�[0m
     Shared Example Group: "basic line" called from ./spec/shoes/line_spec.rb:35
�[36m # ./lib/shoes/configuration.rb:72:in `backend_for'�[0m

backend_for should totally have 2 arguments and it should look like this (from current master):

def backend_for(shoes_object, *args)
    backend_class(shoes_object).new(shoes_object, *args)
end

[ashbb]

Hi all,
Thanks for showing your thoughts.
Frankly speaking, I don't like a big commit. :-P
But okay now, I'll follow your style. ;-)

[PragTob]

I don't like big commits either.

Imo you can/should do commits by fixing problem after problem (that's how I did it in my pull request to your branch, 2 problems, 2 fixes, 2 commits) :-)

[ashbb]

@PragTob Awesome! Thanks to your help, I could merge the commit convert App from module to class without breaking the specs. :-D

@davorb Please check out jruby --1.9 -S rake spec again. After your problem is solved, I'd like to close this thread. ;-)

[wasnotrice]

@PragTob @ashbb I don't like big commits either :)

But the question was how to deal with changes that are trying to solve one issue, and turn out to be really big (because they break a bunch of tests). I prefer one big working commit in this case, rather than 10 small commits, most of which are broken. Feel free to experiment with different methods, though, that's just how I do it :P

[wasnotrice]

Closing. This has become a non-issue.