[ArtificialSoldier]

Quote

we got a system so out of date that the upgrade path includes XP

Goddamn, and I felt like a disgrace for running PHP 5.6 still. Thanks, I feel better now.

[modi123_1]

Spoiler

Look at me, the king of lollypop kingdom dancing around using interfaces, and dependency injection so I can make the gumdrop unit tests cover more.. oooh lalah.

[Skydiver]

Lol! You have just gamified unit testing: Code Coverage Crush!

[modi123_1]

Still not going to write unit tests before I code, but so it goes. Small steps of compromise I guess lead us into that pinko commie revolution through a death of a thousand paper cuts.

In the end I'll have the greatest unit tests anyone has ever seen. Tremendous tests, the biggest bestest tests only devised by the smartest of people.

[xclite]

modi123_1, on 13 October 2020 - 06:06 PM, said:

Still not going to write unit tests before I code, but so it goes.

I support you 100%. TDD code seems to smell a certain way to me... I use unit tests:

1. To prove that a regression was identified and fixed by a code change
2. To simulate edge conditions or error cases that are hard to get with natural execution of the code.

Tests before code just constrain too much and waste my god damned time.

[jon.kiparsky]

xclite, on 14 October 2020 - 10:08 AM, said:

I use unit tests:

1. To prove that a regression was identified and fixed by a code change
2. To simulate edge conditions or error cases that are hard to get with natural execution of the code.

I would add:
3. To add hard documentation of product requirements.

It's way too much work to figure out what the original specified behavior was when we introduce a regression. It's so much simpler, IMO, to write tests upfront. In fact, I've started doing a thing where, on tickets I write or groom for our team, I actually translate the requirements into a minimal set of tests.
I got into this after a few conversations with some of our junior devs, when I realized that they really wanted to write tests, but they were having trouble coming up with the tests that they needed to write. And I found that it really worked - not only did they write the tests, they wrote much better and cleaner tests.

Quote

Tests before code just constrain too much

Just to play devil's advocate here, isn't that sort of the point? To constrain your code to within the bounds of the requirements?

Personally, I don't generally do TDD, but the couple of times I've done it, it's really worked well for me. I suspect that the style of tests you're writing might affect the TDD experience. On my team, we mostly write end-to-end tests, so it's very easy to translate product requirements into test cases. I imagine that if you're writing more unit tests, it might be a bit more of a lift.

[ArtificialSoldier]

Quote

I would add:
3. To add hard documentation of product requirements.

This is important. Based on my experience with certain state-based clients, if we don't have a clear set of requirements, which eventually included on my insistence a set of tests and their results that would demonstrate compliance, then 100% of them time they're going to come back with any change requests trying to convince us that this is what they really meant so we should do it for free.

[NeoTifa]

I get to create a whole new application for work from scratch bros. FINALLY! Build work that isn't just added a new field to a webservice response. I'm so excited, and I can't wait to get started. I haven't been this excited to work in like.... ages XD. Also I finally fixed the stupid defects that caused incidents that have vexed me for like 2 weeks.

This post has been edited by NeoTifa: 14 October 2020 - 11:43 AM

[Skydiver]

Congratulations! As noted above crystallize the requirements in unit tests ahead of time so that they can't later claim that is not what they asked for.

[NeoTifa]

Well, one of the most exciting parts of this is the fact that I can actually write it to actually be able to have unit tests.

This post has been edited by NeoTifa: 14 October 2020 - 01:32 PM

[xclite]

jon.kiparsky, on 14 October 2020 - 12:11 PM, said:

xclite, on 14 October 2020 - 10:08 AM, said:

I use unit tests:

1. To prove that a regression was identified and fixed by a code change
2. To simulate edge conditions or error cases that are hard to get with natural execution of the code.

I would add:
3. To add hard documentation of product requirements.

Agreed, though I often do this with an iTest - shows that we meet product requirements with the real system!

Quote

Quote

Tests before code just constrain too much

Just to play devil's advocate here, isn't that sort of the point? To constrain your code to within the bounds of the requirements?

Ah but it constrains beyond just the requirements. It constrains the parameter list, the return type, construction of attendant systems, etc, which are things that I don't need set in stone yet and, while not germane to the requirements, are germane to the maintainability of the software at large.

I'm going to do the requirement anyway! I don't need a myopic unit test to get there.

ArtificialSoldier, on 14 October 2020 - 12:39 PM, said:

Quote

I would add:
3. To add hard documentation of product requirements.

This is important. Based on my experience with certain state-based clients, if we don't have a clear set of requirements, which eventually included on my insistence a set of tests and their results that would demonstrate compliance, then 100% of them time they're going to come back with any change requests trying to convince us that this is what they really meant so we should do it for free.

IMO, client (but let's be honest, the developer) should provide a functional test suite if they're going to be this way. NOT a unit test, which is the primary model for TDD.

I'm just asserting that a test strategy that operates at the granularity of TDD and at the abstraction level of TDD is a waste of my time. Pre-writing tests? Fine!

[TechnoBear]

I do not write unit tests before code, but I also mainly use unit tests just to confirm that what worked before isn't broken now or to show a basic pass/fail/other response is what is expected before I send it to QA who do the actual testing and edge cases.

[modi123_1]

Mulling over what level of active boots-in-asses I need to get up to, or if I should check myself and accept a more stick-in-my-lane'ness attitude.

F'n-a, some people are scummy.

[astonecipher]

I have my own people are leeches things going on right now!

Today I should be hearing an announcement on my promotion

[h4nnib4l]

Sitting in the 3rd day of Clear Measure's .NET DevOps Bootcamp course. It is usually a week long in-class session, but in Covidworld they've modified it to be 7 2-hour sessions, with 1 session per week and then some not-insignificant homework. I have to say, I'm really impressed with the course. They provide an Azure DevOps template that will completely create the environment, including populating the repo with a functional application and the build and release pipelines, private and CI build scripts, unit/functional tests, and some Selenium acceptance tests. Those templates and scripts alone would have been worth a solid chunk of the registration fee.

The course has definitely helped coalesce a lot of the various "go fast" dev concepts that have lived in separate-but-equal land for me. And the guy is super passionate about all of it, which is always a plus for an in-depth course like this. I honestly don't think I've been this hands on in an instructor-led training since college.