|
I do! EF is super testable. I write unit tests next to integration tests. They serve a different test scope and get treated as such. I feel unit tests give me freedom on what to expect from the API. My EF code ends up prettier as a result of the unit tests. I plan to put something in words around this.
|
|
|
|
|
[quote] I don't see any value in the mocked ones UNLESS the integration tests are really very very slow[/quote]
Exactly.
The goal is to achieve high ratio of Coverage/Test lines.
If the test is too slow, then you can often break it down in several small test or using a mock for a part you don't care for this specific test.
In my recent projects, I used heavily azure storage. The whole difficulty of the code was to design azure table right, and having good RowKey and PartitionKey. By mocking it I would have just skipped the most difficult part of the project.
And there is NO DOWNSIDE to just use the real deal in the tests. As long as the test is fast and repeatable, what is the problem ?
|
|
|
|
|
I don't whine about being sacked, as I said to them, this is the right decision if our view does not fit. I have enough customers to not really care about being sacked.
I know what a unit test is, and I know what an integration one is. But they should not be done "later" or "before" but together, and the two kinds should run after commit anyway.
When people spend more time implementing a mock than doing an actual implementation, then you have a problem. This is what I call "Astronauts", which might be fine if you have deep pocket supporting you.
My metric is test coverage. Either my tests cover stuff, either they don't. That they are covered by a unit test or by a integration one is of no concern, as long as both kind of tests, should be able to run on my dev machine and repeatable.
I am not against mock, I am against people wasting resources writing tests which does not improve coverage.
|
|
|
|
|
At least the company recognizes this a juvenile way to deal with conflict. You are wrong I am right set aside, this behavior hurts already incompetent companies. In the real world not everyone agrees and that is okay. So kudos to that director.
|
|
|
|
|
I am Questioner, Question all expectations (And I know they are non-sense  ) so I then acts like Upholder, dig my own exceptions and fix them 
Find More .Net development tips at : .NET Tips
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
That's actually exactly what a Questioner is meant to be like: they essentially convery external expectations into internal expectations and then uphold them (now that they actually make sense).
I think most devs do this: translate from external gibberish to internally well-formed commands.
cheers
Chris Maunder
|
|
|
|
|
Mostly I meet expectations, but I question them if they are silly, I refuse some if they are stupid, and I'll meet silly and stupid ones if there are damn good reasons for it.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I refuse to question silly ones only to let the work show how stupid the request and requester is thinking they had a damn good reason for an expectation from me that never would exist of my own doing.
Problem is, this doesn't always work as planned. (a thousand  's)
|
|
|
|
|
A real fact though! Nice One!
|
|
|
|
|
I would have to say rebel-upholder
<sig notetoself="think of a better signature">
<first>Jim</first> <last>Meadors</last>
</sig>
|
|
|
|
|
Yep, all those options should have been with check-boxes.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
