#3,286 in Computers & technology books
Use arrows to jump to the previous/next product

Reddit mentions of xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

Sentiment score: 1
Reddit mentions: 1

We found 1 Reddit mentions of xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler)). Here are the top ones.

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))
Buying options
View on Amazon.com
or
Specs:
Release dateMay 2007

idea-bulb Interested in what Redditors like? Check out our Shuffle feature

Shuffle: random products popular on Reddit

Found 1 comment on xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler)):

u/suddenarborealstop ยท 5 pointsr/PowerShell

This is great. i'd like to add:

- it's very handy to keep your unit tests and integration tests in separate files like ModuleName.Unit.tests.ps1 and ModuleName Integration.tests.ps1 to keep things organized as your tests grow over time. If you don't do this, someone reading your code may have to read through every test to determine if a system is being changed each time they are executed.

- When writing integration tests, I've found the pester commands BeforeEeach and AfterEach are very useful for adding live data into external systems before executing the test itself. Some examples might be: Inserting rows into a database, creating AD objects or creating a file. Once the test has completed, the AfterEach function should be used to cleanup or fix any data that may have been left as a side effect of the test. (You might want to clone parts of your prod environment into an isolated test environment using powershell )

- Unit tests should be run frequently and finish executing extremely quickly (ideally in milliseconds.) Integration tests will take longer because they are supposed to deal with external systems/the outside world.

- Automated tests can themselves be refactored to keep them DRY and maintainable.

- It's fine to write utility functions to assist with reducing the amount of test code, as long as readability is not affected at all. "Clever" test code is so much worse than "clever" code without any tests. Been there, done that.

- I haven't properly dived into the Pester / classes problem yet but it looked messy a few years ago and required boilerplate. Would love to hear more about this.

- Object dependencies from 3rd party code is a separate issue, but they will be Integration tests. If objects don't have public constructors / interfaces then they weren't designed to be mocked or tested. Some code may not be possible to test.

For reference:

A really good book i've been reading is xUnit Test patterns: https://www.amazon.com/xUnit-Test-Patterns-Refactoring-Addison-Wesley-ebook/dp/B004X1D36K/ref=mt_kindle?_encoding=UTF8&me=

And the classic Working Effectively with Legacy Code which is amazing https://www.amazon.com/Working-Effectively-Legacy-Robert-Martin-ebook/dp/B005OYHF0A/ref=pd_sim_351_3?_encoding=UTF8&psc=1&refRID=JQG9XXQCMQ2R1K56JNWC