BTW, regarding that PDF, Copey is known for all sorts of heretical counter-opinions too (I remember back in the early days of design patterns and a lot of the OOP conferences of the mid-90's, you'd often find him in the audience heckling speakers on a variety of topics đ )
This rebuts a lot of Copey's arguments https://henrikwarne.com/2014/09/04/a-response-to-why-most-unit-testing-is-waste/
Also note that most of the problems both DHH and Copey bring up are specific to OOP...
A fascinating piece -- much appreciated!! And, bottom line, I think we're in broad agreement: write simple code, use tests to ensure 1. it does the right thing and 2. it doesn't break when we refactor it.... yes?
So, really, the only contention is whether "test-first" actually drives design
?
Yup. Actually, I believe test first does drive design. I just don't think its the only way to write well designed code. And sometimes, its can be over designed for tests, hurting a bit.
And, I'm bad at writing the test first
There's no One True Way(tm)...
Definitely not
@john would it wrong to manually make a file in the test?
That's what I was thinking... I did not give the correct advice on how to do so though.
If StringReader is working for you, you should probably use that.
usually File is too specific a type to work with - eg. it doesnât transition to code that uses a URL or a resource inside a jar
which are common things to want
if you write the code in terms of InputStream or Reader, you can just pass it some source of data and not worry about those details
.readline is doing a fine job of skipping ahead in the csv
right, but you can .readline on things that arenât Files
oh I didnât know that
itâs a method on BufferedReader, which you can make from pretty much anything you would get input from (string, url, file, resource inside jar, âŚ)
also, in clojure, itâs convenient to use line-seq
since you can then use our nice sequence abstractions
(def text-with-spaces-reader
(java.io.BufferedReader.
(java.io.StringReader.
" some csv text here ")))
(with-open [rdr text-with-spaces-reader] (drop 2 (line-seq rdr)))
but Iâd still need to change my function inside the core.clj file in order to get the test to work right?
might not have to
if the thing just wants a .readLine
able thing
peregrine.circle=> (<http://clojure.java.io/reader|clojure.java.io/reader> (java.io.StringReader. "foo\nbar\nbaz"))
#object[java.io.BufferedReader 0x1a1ca2cd "java.io.BufferedReader@1a1ca2cd"]
peregrine.circle=> (line-seq *1)
("foo" "bar" "baz")
http://clojure.java.io/reader is smart about creating BufferedReader
I see
I am trying to use @john âs code to drop 2 since thatâs a much better solution than my current one and I keep getting a âunable to resolve rdr in this contextâ error
did you evaluate the text-with-spaces-reader def
first?
no I am trying to update the function in my core first
because the reader has the with-open in it so I would like to get it working there before I try to figure out testing
what does your with-open for look like?
(with-open [rdr (io/reader file)]
hmmm. Not sure why you'd be getting that error then...
yeah
check your parenthesis and make sure rdr
is in scope
and for some reason when I break it out into a seperate function I stop having the symbol error and I get a problem with ânull pointer exceptionâ meaning something in my data is wrong
really hard to tell, without seeing the code. I'm able to do a line-seq
on a (io/reader file)
over here.
yeah thanks so much for your help sorry I canât be more communicative
Clojure is a whole new world for me
Learning the new idioms takes a minute, but it's worth it đ
it seems like it!
so hereâs a thought - the rdr stream gets passed into a variety of other functions that parse the raw stream into a map
are you implementing your own csv parser?
nope Iâm using the clojure csv
and then there is a function that is unique
it looks like
(let [raw-csv (csv/read-csv rdr)] (doall (csv-data->maps raw-csv)))))
I would make that its own top level function
for testing purposes