|
tax stuff sounds like it should be one of those very unit-testable things - given these conditions, this value should come out. properly done, it should be a pure function. done wrong, it's both rigidly inflexible and impossible to understand guess how well the system i work on handles taxes?
|
# ? Aug 14, 2018 01:10 |
|
|
# ? Nov 5, 2024 21:36 |
|
i should really put together a blog or something on "dealing with money stuff without wanting to kill yourself"
|
# ? Aug 14, 2018 01:11 |
|
Finster Dexter posted:Sorry for double post, but I'm finishing up this talk on Rust. edit: unless kissing a girl means something about error handling to him pangstrom fucked around with this message at 02:17 on Aug 14, 2018 |
# ? Aug 14, 2018 01:55 |
|
redleader posted:guess how well the system i work on handles taxes?
|
# ? Aug 14, 2018 02:02 |
|
Thanks for all the outpouring of advice. who would have thought funny computer forum would be so helpful
|
# ? Aug 14, 2018 02:52 |
|
NihilCredo posted:here's a real life scenario: products have VAT rates. those VAT rates can occasionally change over time, meaning both that a product can be moved to a different VAT rate, or that a VAT rate can be increased or decreased by a percentage point or two (let's keep it simple and say it's one VAT rate per product (it's not)). "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"
|
# ? Aug 14, 2018 03:00 |
|
cheque_some posted:Thanks for all the outpouring of advice. Nobody in yospos is funny so they have to be good at something
|
# ? Aug 14, 2018 03:10 |
|
jit bull transpile posted:Nobody in yospos is funny so they have to be good at something that's not fair, we're all terrible at programming
|
# ? Aug 14, 2018 03:17 |
|
I have it on good authority that I am funny looking, Jit.
|
# ? Aug 14, 2018 03:30 |
|
toiletbrush posted:It's interesting how you can break down each instruction 'family' like MOV and figure out what registers it's dealing with just from looking at the opcode "opcodes let you know what the instruction does"...is that what you're saying here? big if true
|
# ? Aug 14, 2018 03:40 |
|
Lutha Mahtin posted:"opcodes let you know what the instruction does"...is that what you're saying here? big if true This is why it's important to learn assembly kids. Turns out, computers are in fact not magic
|
# ? Aug 14, 2018 03:48 |
|
the talent deficit posted:"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" reminder that this was an mp skeptical of babbage's machine being a farce rather than an mp who had no idea about which what they were looking
|
# ? Aug 14, 2018 06:27 |
|
jit bull transpile posted:Nobody in yospos is funny so they have to be good at something conclusion does not follow from premise imo
|
# ? Aug 14, 2018 06:32 |
|
whats the point of tests if nothing works anyway somehow i get paid
|
# ? Aug 14, 2018 06:47 |
|
my new dog posted:whats the point of tests I need a shirt of this
|
# ? Aug 14, 2018 07:48 |
|
pangstrom posted:Whoa. If that guy ever asked me if I had kissed a girl I would kill myself. what
|
# ? Aug 14, 2018 07:48 |
|
eschaton posted:try doing this quoting from way back, but learning vi is pretty much the equivalent to picking up smoking. i've tried quitting vi off and on for like 15 years and i always keep coming back.
|
# ? Aug 14, 2018 07:58 |
|
that's a good analogy
|
# ? Aug 14, 2018 08:05 |
|
MononcQc posted:Can you define what you mean by "wrong rate", like basically the VAT should be denormalized and stored at the time of the invoice rather than mutating with the current rate the entire way through? Mostly. When you create an invoice, but haven't yet published it (= sent it to the client or other third parties), then every time you open it the VAT rates should update to the current values. Once you publish it, VAT rates are locked at the date of publication, so if you open it (you can still make some changes after publication, like adding notes) it shouldn't update the VAT rates anymore. But, if you make a duplicate of the invoice, it should act like a newly-created one, with up-to-date rates. Oh, and if you make a credit note from the invoice, the credit note has the current date but it must keep the old VAT rates. One can see that every sentence in the above paragraph can be expressed quite straightforwardly as a test or two, but if I've never tested anything more complicated than string parsers so far, I'm likely to make those tests brittle or vacuous or just way more work to write and maintain than they need to be. MononcQc posted:<stuff> Yes, I'd really love to see or read someone take this outline you've written and go through all the nitty-gritty details and complications that arise. How should the test invoices look like? Should it just use the current date, or fuzz values, or explicitly test 'dangerous' dates around New Year's (when invoice numbering resets)? Would it be a good idea to write a list of test invoices covering every corner case you can think of, and then share them between all tests? Customers can be set to 'VAT exempt', how do I set up the tests so they run for both exempt and non-exempt customers (and I don't want to read another loving "oh, you're testing the behavior of *two* classes, well technically it's an *integration* test now, sorry, this book is only for unit tests" evasion). quote:But yeah, having mostly finished writing a testing book, a big problem is that interesting tests require interesting codebases to demonstrate stuff, and having to introduce an interesting system just to test it after the fact is a hell of a lot of work (both for reader and author), and it's hard to make it interesting to the reader. You've got to dump a bunch of code going "this is not actually relevant to the lesson in this chapter but you have to go through it anyway, sorry!" See, this is exactly what I think a book should be *for*: a well structured tutorial that can afford to take the time to properly set up the stuff it's trying to teach. If it's complicated stuff and it takes a hundred pages to do it justice, then it takes a hundred pages, and critically, *only* a book can do that. I won't find it anywhere else, short of hiring an experienced engineer to do pair programming. If I wanted a bunch of rapid tutorials with simple examples that are more preoccupied with being interesting than useful, then I'd look for a series of articles on a blog, not a book. NihilCredo fucked around with this message at 08:44 on Aug 14, 2018 |
# ? Aug 14, 2018 08:40 |
|
Stringent posted:quoting from way back, but learning vi is pretty much the equivalent to picking up smoking. it’s useful if you ever ssh into a barebones linux, or if you sudoedit without remembering to set EDITOR and can’t be bothered to change programs here is a complete cheat sheet of vi commands worth learning:
|
# ? Aug 14, 2018 09:19 |
NihilCredo posted:I'd really love to see or read someone take this outline you've written and go through all the nitty-gritty details and complications that arise. How should the test invoices look like? Should it just use the current date, or fuzz values, or explicitly test 'dangerous' dates around New Year's (when invoice numbering resets)? Would it be a good idea to write a list of test invoices covering every corner case you can think of, and then share them between all tests? Customers can be set to 'VAT exempt', how do I set up the tests so they run for both exempt and non-exempt customers (and I don't want to read another loving "oh, you're testing the behavior of *two* classes, well technically it's an *integration* test now, sorry, this book is only for unit tests" evasion). If there's a stub implementation or just more formal/step-by-step description of this domain available somewhere you can share, I would love to take a crack at this to be honest. I'm terrible obv but this is fascinating to me and I'm trying to become more test-focused in both implementation and execution. Plus this thread is inspiring me to try and do some more 'homework'. Like, in general the question sounds like one of a series of different transformations and mutations that ideally would be isolated and therefore easy to test but there's some juicy cascading effects going on. My naive instinct would be to use a bunch of consecutive service functions and maybe use some nesting test setups (a la jasmine in the JS world) to make the combinatoric situation not explode.
|
|
# ? Aug 14, 2018 09:20 |
|
Soricidus posted:it’s useful if you ever ssh into a barebones linux, or if you sudoedit without remembering to set EDITOR and can’t be bothered to change programs after a few years i have upgraded my repertoire to include dd which deletes the whole line and saves me holding down backspace for 10 mins at a time
|
# ? Aug 14, 2018 10:37 |
|
You must absolutely make your unit tests deterministic. So yeah hard code some plausible minimal test cases into your code. In situations where randomness is required your classes under test must take an RNG as a constructor param and you should supply an RNG that was initialized with a hard coded seed. Definitely have test cases for edge cases like new year. Seems like vat rates are a time series that requires a snapshot capability, so yeah build that whole time series service as a separate unit with its own separate unit tests. All else being equal you want your vat calculator (or anything else really) to have the data pushed to it instead of making it pull things. Vat exemption, well, no universal answer for that. Maybe you want your calculator to take a TaxRegime interface and have a method on that interface that takes the invoice date and whatever other properties the tax man cares about. Then have a PrivateCustomerTaxRegime and a VatExemptRegime where the latter returns a zero tax rate for everything and have an upper layer locate a suitable tax regime given a Customer object. Then test that upper layer separately. Sounds like you have an Invoice object with an effective date, a list of line items, and your tax calc function takes an Invoice and a TaxRegime. Elsewhere you have some other function that locates a TaxRegime given a Customer which you can test separately, and some other thing above all that to execute all the steps of the process. Or maybe that is a poo poo design idk. I don't know what the entire requirements doc looks like. So, push not pull where possible, think very hard about what your business logic should be a function of and cut the task into pieces accordingly, and let your testing plan inform your system design instead of the other way around.
|
# ? Aug 14, 2018 11:08 |
|
lol if you have to deal with time zones and/or any naive time really get a library dude
|
# ? Aug 14, 2018 11:24 |
Sapozhnik posted:let your testing plan inform your system design instead of the other way around. This is really such a good point. The amount of headaches this saves is amazing.
|
|
# ? Aug 14, 2018 12:02 |
|
today in terrible programming: my boss said to me: "hey boiled can we remove the square brackets from the json output? yeah the ones demarking arrays, our scandi customers are having trouble parsing them"
|
# ? Aug 14, 2018 13:18 |
|
Sapozhnik posted:So, push not pull where possible... I have to remind myself this all the time. I'll start fretting about how a function needs to call all these other functions to get the data it needs, then, after far too long, realize I should be passing in that data instead. Along the same lines, I'll stare at a blank screen for a while before realizing that I can just start with the most obvious piece and build from there.
|
# ? Aug 14, 2018 13:23 |
|
Sapozhnik posted:You must absolutely make your unit tests deterministic. So yeah hard code some plausible minimal test cases into your code. In situations where randomness is required your classes under test must take an RNG as a constructor param and you should supply an RNG that was initialized with a hard coded seed. also to compound on this, if anything is time-based (now(), etc), make sure whatever functions you write let you pass in the current time, so you can test it. basically: code:
|
# ? Aug 14, 2018 13:36 |
|
Well in that specific case it may be better to pass a Clock, but of course it depends on the exact task at hand
|
# ? Aug 14, 2018 13:54 |
|
Sapozhnik posted:Well in that specific case it may be better to pass a Clock, but of course it depends on the exact task at hand well yeah, i was trying to simplify it.
|
# ? Aug 14, 2018 13:56 |
|
This is where purity lessons from Haskell are interesting to borrow from. If code handles time, as much as possible make that pure. Whatever date or value to use, someone hands it to you. If you have a file from which you read content, read the contents externally and only pass in the bytes/string/stream to whatever consumes it. This makes it really easy to then test these components by passing them all the edge cases without needing to control the environment strictly, though you'll need some kind of higher-level view that deals and copes with all the side-effect injection. It's not always realistic and working in all places, but there's often an interesting way to go about these things if you want to ease testing and analysis.
|
# ? Aug 14, 2018 14:03 |
|
best thing is that if you are writing with testing in mind, not only is it easier to test your code, it really enforces thinking about some design decisions that will improve your code in general. you can also go overboard though: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition I'm the LoopContextStateManipulation.java LoopContextStateRetrieval.java LoopPayloadExecution.java LoopCondition.java LoopContext.java LoopFinalizer.java LoopInitializer.java LoopRunner.java LoopStep.java
|
# ? Aug 14, 2018 19:06 |
|
wow gitlab is just way better than bitbucket
|
# ? Aug 14, 2018 19:12 |
|
MALE SHOEGAZE posted:wow gitlab is just way better than bitbucket I disagree. Gitlab's UI is consistently hard to read. It definitely has more features than bitbucket, but the bitbucket UI doesn't give me eyestrain trying to find the button or link that I need to do a thing. I dunno, part of my bias could be the fact that the bulk of my gitlab experience has been from the on prem gitlab our Russian contractors are using. Everything is English, but drat it's hard to look at compared to bitbucket or github.
|
# ? Aug 14, 2018 19:21 |
|
we use phabricator at work and i'll never go back
|
# ? Aug 14, 2018 19:43 |
|
CRIP EATIN BREAD posted:we use phabricator at work and i'll never go back phab is good as hell but they note right there on their front page that they use php so "even babies and dogs can contribute (with supervision)"
|
# ? Aug 14, 2018 19:48 |
|
gonadic io posted:after a few years i have upgraded my repertoire to include dd which deletes the whole line and saves me holding down backspace for 10 mins at a time watch it, that's how it gets you.
|
# ? Aug 14, 2018 20:18 |
|
bob dobbs is dead posted:phab is good as hell but they note right there on their front page that they use php so "even babies and dogs can contribute (with supervision)" for awhile on their site navigation bar there was a link just titled "pokemon" that just listed off different types of pokemon. its a good piece of software.
|
# ? Aug 14, 2018 20:33 |
|
learn ed and become better at vi
|
# ? Aug 15, 2018 00:13 |
|
|
# ? Nov 5, 2024 21:36 |
|
Finster Dexter posted:I dunno, part of my bias could be the fact that the bulk of my gitlab experience has been from the on prem gitlab our Russian contractors are using. i didn't realise you wrote software for voting machines
|
# ? Aug 15, 2018 06:10 |