Modern Dev Practices Unit Testing high
ฝัง
- เผยแพร่เมื่อ 6 ก.ย. 2024
- In this episode, Robert is joined by Phil Japikse, who explores how in modern development practices, unit testing is part of the development process, not a chore to be tackled after you write your code.
Phil spends most of the time on Test Driven Development (aka Test Driven Design), where you write a test first and then write just enough code to pass the test and then refine the code as you add more tests. In TDD, the tests embody the requirements the code must satisfy.
He also briefly covers Behavior Driven Development [50:20] and Mocks [53:45].
Resources:
- Follow Phil Japikse: / skimedic
- Sample projects: github.com/ski...
- xUnit.net: xunit.github.io/
- Machine.Specifications: github.com/mac...
- MSpec Visual Studio Test Adapter: marketplace.vi...
Thanks for this great discussion! ❤
"I don't quote statistics, because 90% of them are made up anyway." I really hope other people caught that one, lol.
It’s worth adding that for anybody new to TDD, mocking can be... problematic. If not used correctly, they can cause problems where tests are way too aware of implementation and you completely lose the benefit of faster extension and refactoring because you end up needing to rewrite all the tests. In the worst cases I’ve seen mocks that are essentially duplicates of the code, such that you aren’t really testing the method anymore - you’re testing the mock implementation.
This can make people less likely to want to refactor, and there is always the chance of losing a requirement in the process.
I’d also suggest looking more into rolling your own dummies, stubs, spies, and fakes. It doesn’t necessarily fix the problem above - that really just comes with experience. But personally it makes the process a lot more clear in cases where you do need to rewrite tests.
tl,dr - be thoughtful of using mocks. It’s probably a code smell if you’re having to write a) a lot for a single test or b) overly complex ones with behaviors based on inputs
"Modern Dev Practices Unit Testing high" ... high?
I'm assuming that that's a literal statement about the mental states of the presenters.
Development is not a typing skill but thinking skill...that hit me hard.
excellent video, thanks Robert and Phill great explanations! unit test is a very powerfully tool and more awesome TDD!!
I tried following along high and it didn't go so well
Great overview! Thank you!
mock.Verify(foo => foo.Find(12)); - What will be if I want to refactor GetCustomer? For example change Find(); to GetById(); The test will fail. Why you need a test you must change every time you change implementation of SUT? Such tests are wasting of time. Sandi Metz says: Test interface not implementation. What do you think about it?
Refactoring methods is pretty easy in visual studio, ngl
How can we Unite test a software for an machine? Wich moves for example forward and backward? So we have most likely only certain times the actual hardware where we could run that program because it is a very expensive Maschine and we can’t borrow it from our customers for unit testing. Should we only test that parts of software that are testable without the massive Maschine?
Maybe mocking the machine input data, and creating test based on that?
There is an edge in which unit tests cannot reach. A this point you make the edge as thin as possible, so if it is moving a part your classes at that edge have no post processing of the input data as possible. So in the terms of driving a physical device your edge class should be as simple as MoveLeverMM(int mm), implemented via a IMachineMovement Interface. You should already know what the limits of the machinery are., so your tests ensure that the values passed are expected as part of a larger integration.
Ultimately, testing machinery without an emulator, which uses an implementation of IMachineMovement is never a good way to build a system which is driving machinery. Otherwise you need to always use the machine.
The creation of the machine emulator should be the responsibility of another team and it should mirror exactly the machine, down to emitting events and diagnostics as if it was the machine. Any gaps in the emulator in terms of virtually implementing the behaviour of the machine will prevent confidence in the behaviour of the whole system.
If you have an API from the machine vendor then this should be implemented within your IMachineMovement interface, protecting your actual code higher up.
Ultimately, protect everything with an interface and create adapters around systems that are not explicitly under your control, be it a 3rd party library or hardware interface. Anything running through an interface can be mocked, stubbed or emulated.
If you already have the software written, refactor an interface between the hardware and your code and get an emulator built as soon as possible.
This video does cover all this, but take a look at "Working effectively with Legacy code" and the Mediator or Adapter design patterns.
Hope this helps.
I think your adding more time to check your tests by not leveraging what VS already has which is making your tests run every time you build. the button is on left corner of you test explorer.
now it's Live Unit testing so it runs them as you type :)
thanks!
How about writing test is not fun ?
thanks
I think it is the best 2010 version.
TDD is the biggest waste of time for everyone on a team. Seniors catch it on code review. Juniors learn from the code review. There's only so many ways you can mess up.
Why have you chosen to deliver content over the period of an hour which is of such a fundamentally low entry level to be useful.
Build a function that does one thing. Write 40 tests to see if it does. Not for me.
40 "tests" is not much. For example a mail validator, you assert ~10 valid mails in a positive test and ~10 invalid mails in a negative test (with edge cases). In total these are 20 tests already bundled in a data factory / assertAll and every single one needs to pass and you need such amount for this use case.