I think tax is actually one of those situations where you do actually want to do it with code; each year they introduce random changes, which means that your tax tables are going to be pretty complex. That doesn't mean code that isn't parameterized, it just doesn't need to be in a DB. The values change once a year (pretty much) on a pretty predictable schedule. But it really depends; it's even worse if you need to be able to calculate the tax on things for different financial years; that's going to make the generic solution even stranger. Putting it in code also probably makes it more testable, rather than less. But who knows, a NoSQL definition of a combination of tax calculator objects might be good.
But yes, kind of off topic. I'd go the parameterized specs in a loop route, as you basically want to test a few edge cases for each bracket, which would get pretty long and unreadable pretty quickly. Also, Mikel is correct about a Money class -- don't use floats anywhere related to money. Integers (as in number of cents) are a reasonable second option, but something to hide it all is nicer. As Mikel also mentioned, explicitly test rounding as well. Simon. On Fri, Sep 2, 2011 at 15:48, Adam Boas <[email protected]> wrote: > Sounds a little like mixing concerns to me. Regardless of how easy it is or > isn't to deploy your code, tax tables aren't really an application logic > concern. Maintaining tax tables in code would probably lead to potential > copy errors and would need to be maintained by people who likely don't > understand them. Having them in a database, and potentially uploadable from > spreadsheet, puts the management of them in the hands of tax people who can > manage and verify their voracity. > > Adam Boas > m:+61 (0)457 741 117 > e:[email protected] > > > On 02/09/2011, at 3:32 PM, Ben Hoskings wrote: > > Deploying your app should be easy enough that that doesn't matter. > > You have to change the values somewhere -- if they're stored in the DB, > you're changing them in an admin interface. I'd rather use my editor and > git. :) > > Also, this way, you update the specs along with the rates, which reduces the > chances of cock-ups. > > - Ben > > > > On 02/09/2011, at 3:22 PM, Anthony Richardson wrote: > > Should the tax rates be loaded from a database in your app? > > With your current solution you will need to rewrite your application and > > tests each year they change the tax rates (often). Not to mention special > > cases like the flood levy. > > Cheers, > > Anthony > > > > On Fri, Sep 2, 2011 at 12:04 PM, Michael Gall <[email protected]> wrote: > > Hi guys, > > I'd love to get some feedback on a spec I'm writing. It's a tax calculator > > for australian taxation rates - nothing too complex just yet, but some of > > the calulation specs feel wrong, but I don't know a better way. > > Thanks in advance. > > > describe TaxCalculator do > > describe "low income bracket" { > > before { subject.income = 5000 } > > it { subject.calculate.should == 0 } > > } > > describe "15c tax bracket" { > > before { subject.income = 10000 } > > it { subject.calculate.should == 4000 * 0.15 } # the tax bracket is 15c > > in the dollar between 6000 and 37000 > > } > > describe "30c tax bracket" { > > before { subject.income = 50000 } > > it { subject.calculate.should == 6000 * 0 + 31000 * 0.15 + 13000 * 0.30 > > } # the tax bracket is 30c in the dollar between 37000 and 80000 > > } > > end > > > Cheers, > > > Michael > > > > > -- > > Checkout my new website: http://myachinghead.net > > http://wakeless.net > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby or Rails Oceania" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/rails-oceania?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]. > > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
