Comments (19)
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
from shoes4.
I'm currently working on your branch gtrying to get those tests passing, good exercise to familiarize myself with the architecture :-)
from shoes4.
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
(847) 859-9550
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.
Thebin/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
from shoes4.
For general progress you can refer to this pull request on ashbbs fork.
from shoes4.
@ashbb this is how I have been doing it:
- Make the fix I'm working on. Commit.
- Notice that it breaks a lot of tests.
- 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?)
- Fix broken tests.
- Fix broken code. Commit.
- Fix broken tests.
- Fix broken code. Commit.
- More of this :)
- When all of the tests are passing again,
git rebase -i master
and squash everything down into one commit - 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 :)
from shoes4.
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
(847) 859-9550
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:
- Make the fix I'm working on. Commit.
- Notice that it breaks a lot of tests.
- 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?)- Fix broken tests.
- Fix broken code. Commit.
- Fix broken tests.
- Fix broken code. Commit.
- More of this :)
- When all of the tests are passing again,
git rebase -i master
and
squash everything down into one commit- 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)
from shoes4.
Oh, forgot to mention, I do all that on a topic branch before merging back into master :)
from shoes4.
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.
from shoes4.
@davorb What tests are broken in master? Travisci says the build is green. I agree, master should be clean.
from shoes4.
@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.
from shoes4.
@wasnotrice I just did a fresh checkout and it failed on Windows 7. Worked just fine yesterday.
https://gist.github.com/2903472
from shoes4.
@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.
from shoes4.
@davorb @ashbb @wasnotrice green on my Linux machine as well
from shoes4.
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
from shoes4.
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. ;-)
from shoes4.
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) :-)
from shoes4.
@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. ;-)
from shoes4.
@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
from shoes4.
Closing. This has become a non-issue.
from shoes4.
Related Issues (20)
- Included files aren't found by the app HOT 2
- Poignant Guide / Nobody Knows Shoes link problem HOT 3
- bootup time of a simple app HOT 1
- No gems found matching '' HOT 2
- Using "link" breaks the app HOT 5
- Try out Travis Windows build environment?
- mac install error HOT 1
- package problem with music
- Need an Invite HOT 1
- Shoes overwrites the Windows environment variable HOT 3
- HiDPI Displays
- Image Clearing HOT 2
- nokogiri gem is unstable HOT 1
- Not able to drag windows? HOT 7
- No route to host on installing gem HOT 4
- Is this project dead? HOT 2
- Cannot install Ruby Shoes 4 HOT 14
- Comodos
- Roll Call - users / developers / "Is this thing on?" HOT 5
- Shoes joining forces with Glimmer? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from shoes4.