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 .readLineable thing

peregrine.circle=> ( (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