|
Then, nobody will have any expectations of me (including myself)
|
|
|
|
|
I am bad! Question all the things.
|
|
|
|
|
I'd say I'm a washover.
I let inner and outer expectations washover me, if I meet them that's cool, if i don't well it just didn't happen.
i refuse to stress myself out trying to meet expectations
Pete
|
|
|
|
|
True story :P
 -ank
|
|
|
|
|
but according to that list I'm a rebel...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
When it comes to my own personal projects. I have so many in personal projects on paper for the past 5 years but they have never ever met reality.
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
Make your list shorter - maybe really short. So short you can make it.
Remember: life is getting shorter every day 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
My list is now empty. 
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
None of the above, as (no doubt) so many others will note. In the non-pimping sort of way, I'm an enabler and a problem-solver.
I see things that should be done better/more easily, and make it easy for others to do them.
Problem solver needs no real explanation and the two are symbiotic.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I like to play devils advocate, question everything that someone wants, and you'll usually find they don't actually want what they asked for but something completely different.
Afterall, the customer never really knows best.
|
|
|
|
|
I am a rebel. 
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
I already lost a customer long time ago.
Basically I was complaining because their unit test strategy was a big pile of sh*t, everything was mocked up so nothing was really tested... But you had to write the tests and solve the 999999 mocked dependencies which goes with it on every tests... And setting up the expectations of each of the dependency with Moq, at every test.
Most time was spent debugging the expectations than testing the actual code... which was not really tested since most of things were mocked.
One day I said: this is bullshit, I'll remove those mock and use a real embedded database for tests (which are cleared after each run), so at least something (the NHibernate layer) would be tested.
It worked well on my machine, but exploded on CI server. My team was mad at me, I apologized, and asked some time to fix the problem. They told me to stop trying what I wanted to do, I said I won't... So they fired me.
Well, after that the director of the company contacted me again, I explained my position and said it was unfortunate and leaving was indeed the best solution for all...
The director decided that I had the right behavior, even if I was not fit for this team, so he asked me if I was interested into working on another project for his company.
Never had any regret for being questioner even if it creates tensions, I value my time too much for working on bullshit. As long as you keep the head cool and show respect, problems are rare.
|
|
|
|
|
The way I see it, dependencies of a class under test should be mocked, because they are not the object of the test(s). Granted, it can be tedious to set up expectations on mocked dependencies, but the effort serves a valuable purpose: it prevents the unit under test being affected by unpredictable external behavior. A consumer of the NHibernate layer is not the appropriate place to test the behavior of the NHibernate layer, which should have its own suite of unit tests elsewhere to prove its correctness. I have to say I'm with your former team on this one.
|
|
|
|
|
And I am telling you it is bullshit. In production your NHibernate code will run, if you have not tested it, and kept everything in your small curated bubble then it will break in prod as well, defeating the whole purpose of tests. The purpose of writing tests is about testing code which will run in prod, not about testing mocks.
I am not against mock for some part which use external service though, just against the "mocking everything" mania, as too often they end up testing nothing at all, while wasting everybody's time.
Also, if you use inmemory database, your code WILL be predictable and you will have higher test coverage.
If you don't use inmemory database, you can still have predictable run by cleaning the database before the test run.
These are not unit tests, but tests that can be run in CI, or manually if you want to debug a particular bug.
The distinction between unit test and integration test is also bullshit. When you commit, your tests will all run in CI anyway.
modified 4-Jan-16 22:24pm.
|
|
|
|
|
If you think unit testing has anything to do with testing mocks, then I feel you may have a misguided view of this testing strategy. That you see no distinction between unit and integration testing is more evidence of the same. Unit tests are (typically) small, isolated, rather specific, and can often be written very early in the development process, precisely because they have no dependency on anything outside of the unit under test (apart from the test code itself, of course). They give the developer early and ongoing evidence of the correctness of smaller parts of a larger application or system, one that may not yet be in a functioning (and therefore integration-testable) state. This is the important distinction between the two testing methodologies: integration tests, unlike unit tests, require a reasonably complete set of functioning dependencies, and so cannot be written until relatively late in the development of the application. As a newcomer approaching a mature application that has all or most of its functioning parts already in place, I can imagine how tempting it might be to view the unit tests as superfluous and noisy. After all, integration tests are possible at this stage, are more likely analogous to production usage, and might even be simpler to implement what with not having to set up all of those tedious mocks. But the unit tests likely served a very important purpose in helping the application get to where it is now, and—believe it or not—are still helping out by standing sentry against the omnipresent threat of regression, so they may have more value than the näive newcomer suspects.
That unit tests may represent a potentially large volume of non-production code is not, per ipsum, a compelling argument against them. According to your OP, you took issue with the organization's existing unit testing strategy, and took it upon yourself to replace existing unit tests with integration tests. That your team didn't like this activity is unsurprising; I think they were probably correct. This is not to say that you made the software necessarily worse by your efforts, but does mean you might have done, and it is likely your refusal to concede the point that got you sacked. Totally fair.
|
|
|
|
|
Just my 2 cents...
I find testing NHibernate and Entity Framework a PITA, because if I want a test that gives me some actual value, it needs to touch the database. After all one is a concrete IQueryable and the other is most probably an IEnumerable (or at most, an implementation of IQueryable based on IEnumerables).
In my experience problems in that kind of code show up during the conversion from linq to SQL, so unless you have the whole thing set up you cannot be really sure it's going to work.
I am aware that this makes the unit test become an "integration test", but since a mock based unit test would have to be complemented by an identical test with the real db to test the ast's, I don't see any value in the mocked ones UNLESS the integration tests are really very very slow. Only then it might be worth to mock the DB so you can rely on actual unit tests during development.
If anyone has a better idea then by all means PLEASE PLEASE PLEASE share it!
|
|
|
|
|
Personally, I mock the EF classes within Unit Tests for other classes.
The data layer code itself needs to be tested thoroughly. Alongside writing the above Mocks, if I find myself using EF features not exercised elsewhere, I add data layer tests - these are integration level tests, necessarily. Naturally, they are designed to ensure that data access code doesn't fall over when accessing a real DB.
I run Unit Tests as part of my compile-test-refactor cycle, and integration tests before commit.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Why separating both ?
Imagine you have a Controller and a Repository.
In one test you will inject mock repo in the controller and test the controller.
In the second you will create a real repo test it.
Why not doing one test which test the controller with the real repo injected ? it achieves the same code coverage, for less code.
Even better! It ensures that the controller does not pass unsupported values for the real repo.
Such test, even with a database takes less than a second to run.
Running all tests at every compile have never been useful for me, so long as the CI server do it for me.
|
|
|
|
|
Quote: Why separating both ?
These are Unit Tests. There very purpose is to ensure that a particular Unit (module) functions as required, independent of the other Units. It helps ensure that Separation of Concerns[^] is practiced properly.
Nicolas Dorier wrote: Such test, even with a database takes less than a second to run.
And if you have a set of 20 or more such tests, that increases the time to run your unit tests by 20 or so seconds. The CI server will do the kind of testing you're talking about (Integration Tests). I prefer to have Unit Tests run frequently - that is their entire purpose. Personally, I use Test-Driven-Development practices as much as possible, which means that the Unit Tests help drive the entire development process. If they take too long to run, they break the smooth flow of development.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Because you've tight coupled your repository to the controller. Unit tests promote decoupled components that do one thing. It's part of SOLID principles.
|
|
|
|
|
I know what is solid principle, my point is that making 2 unit test: 1 testing only controller with mocked repo, and the other testing only repo is a waste of time.
Making one test which test both at the same time take less time, and at the same time have higher coverage and test actually what will run in prod.
To make things matter worse, the most complex code is often in those repository, by mocking them you are not testing what matter.
|
|
|
|
|
An integration test covers the repo. The controller is a separate concern. Decoupled, testable code is not a waste of time. SOLID principle Dependency of Inversion states you code to abstractions, not implementation details. By jumbling the repo with the controller you violate this principle. The goal is to delegate implementation details through separate contracts. It does not matter how you do it and that my friend is testable.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
