This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-27
Channels
- # aleph (1)
- # aws (2)
- # beginners (69)
- # boot (79)
- # braid-chat (1)
- # cider (221)
- # clara (13)
- # cljs-dev (9)
- # cljs-edn (1)
- # cljsrn (7)
- # clojure (128)
- # clojure-chicago (1)
- # clojure-russia (196)
- # clojure-sanfrancisco (1)
- # clojure-uk (13)
- # clojurescript (166)
- # community-development (2)
- # css (2)
- # cursive (8)
- # datomic (4)
- # emacs (11)
- # hoplon (54)
- # instaparse (2)
- # jobs (16)
- # jobs-discuss (54)
- # jobs-rus (7)
- # luminus (4)
- # off-topic (33)
- # om (37)
- # onyx (8)
- # proton (10)
- # quil (8)
- # re-frame (29)
- # reagent (7)
- # remote-jobs (2)
- # untangled (140)
- # yada (1)
Guys, I have one non-related to Clojure question. Should a programmer add unit tests for private methods?
If this method was extracted from bigger public one only for readability anf consistency
If you feel a need to test a private function/method then this may be an indicator of some abstraction missing
@thebeatcoder: you can just test the abstraction for the cases that private function covers
@thiagofm do you mean test it indirectly by covering public methods using that private one?
I follow the same principles but I'm debating w/ my colleagues abot that
@thebeatcoder: your private function should do something. Add a number, log something, write something to a file, anything. You can write a test case that given that you ran the public function, you got the behavior expected from that specific private function, or that your public function gives the right results(so the private fn has to be working).
@thebeatcoder: there's plenty of discussions regarding that on google which have way more words than I could provide to you. There's no absolute truth of course.
@thiagofm definitely, I just want to get different points of view for this question. Thank you!
As for me, direct testing of private methods is like "refactoring hell" because any structural changes that should be changed on first-class member redound on fixing existing unit tests, writing others with similar assertions etc. And, of course, nobody will want to do any refactorings on the existing codebase in such case.
I suggest that a workable middle ground might often be "test private functions if they're complex but you (and colleagues) have carte blanche to delete the tests if/when you make changes that mean they start failing"
sometimes it's helpful to write tests to drive the current implementation, sometimes the tests you write are useful records of the specification, but not every test always can perform both roles
I finally got my dead tree copy of SICP! Now, I figure I need a scheme implemenation to follow, what would you guys recommend? Can racket fit the bill?
@bojan.matic: I think you can do it nicely with racket, perhaps you might have a thing that is different or two, but adapting for those should be straightforward
can I get a scheme that would require 0 adapting?
or is there no more such a thing?
@bojan.matic: gambit scheme perhaps?
But I wouldn't worry about that detail. I think the whole book is way more about problems/reasoning than a specific programming language.
i just thought it might be easier to not bog myself down in language details
oh, video lectures?
first time hearing it
They are kind of old, but all applicable today, and of course, are based in the content of the book.
@bojan.matic - http://blog.spike.ninja/setting-up-a-racket-environment-for-sicp-that-doesnt-suck/
who's joining the Lisp Game Jam? 😄 https://itch.io/jam/spring-2016-lisp-game-jam